Gmail and Yahoo are implementing a new policy that will affect the deliverability of your emails starting on February 1, 2024.
If you have a website with your own domain name, and if you send emails from an email address associated with that domain name, DMARC matters.
*******February 2024 Clarification********
If you DON’T have an email address that ends with your domain name (like Bob@BobSmith.com), you’re in trouble now that Feb 1 is behind us. Most (if not all) newsletter providers won’t let you email your readers from a personal email address that ends with @gmail.com (or similar). So if that’s you and you thought you were good, you’re not. Go get yourself a professional email address associated with your domain name (from your hosting, GSuite, or Microsoft), update your newsletter provider to use your new email address, and come back to read about DMARC.
This article will walk you through what you should do with as little techno-talk as possible.
Who should read this?
Do you have an email address associated with your domain name, like bob@bobsmith.com?
Do you use that email address to…
- send newsletters to your readers (one-time campaigns and/or automations to deliver freebies, for example)?
- reply to readers’ email messages?
- send emails from your website when someone fills out a contact form?
- send calendar invitations?
- process orders on WooCommerce, Shopify, and/or emails from Klaviyo?
- forward to a Gmail address that you then reply to readers from?
- connect to another service that emails on your behalf (for projects, billing, scheduling, planning, etc.)?
If you said YES to ANY of the above, you should read this article and take action before February 1, 2024.
February 1, 2024
Gmail and Yahoo are implementing a new policy that will impact the deliverability of your emails starting on February 1, 2024.
If you’re anything like the typical author, a LOT of your readers are using Gmail or Ymail or similar email addresses.
This means that your emails might not reach a sizeable chunk of your readers if you don’t take action.
Fortunately, the “Bare Minimum” solution only takes a few minutes of your time to implement.
If you don’t want (or care) to understand what this is all about AND if you already know how to edit DNS records, click here to get to the instructions.
But I recommend you take a few extra minutes to read on so you understand WHY you are doing this, why the “Bare minimum” may not be what you want for the long-term, and how you can access your DNS records to make the recommended change(s).
What is deliverability?
The likelihood that readers will receive your email messages in their inbox (instead of bouncing, or going to spam/ promotions tab).
Deliverability isn’t something that just “happens” on its own.
As the owner of a domain name, you need to create or edit certain DNS records that prove that:
- You own the domain name in question; and
- You give permission to a service (your website / MailerLite / ConvertKit / Google / Microsoft Outlook / etc.) to “use your domain name to send emails” or what I will refer to as “emailing on your behalf” for the rest of this article.
More on those DNS records later.
Your previous history as a sender and your readers’ reactions to those emails also affects deliverability. (If everyone is marking you as a spammer, DNS records won’t be able to fix that!)
But back to DMARC.
First, I want to explain why this DMARC policy is being implemented so you understand the big picture.
Enters DMARC
In simple terms, Gmail and Yahoo want to protect their users’ inboxes and do their best so they don’t get flooded by spammers pretending to be someone they are not.
DMARC stands for
Domain-based
Message
Authentication,
Reporting, and
Conformance.
With DMARC, email providers like Google and Yahoo are trying to turn their customers’ email inboxes into fortresses where only the “real” senders for a domain name should be allowed access.
DMARC is a good thing.
It will help reduce fraudulent emails that trick people into clicking on links that lead to terrible things: malware, ransomware, sending money to people impersonating you, etc.
I’m sure you’ve gotten your fair share of emails from sneaky individuals who pretended to be someone they’re not.
Fixing impersonation problems can be tough…
In real life, we can look at an ID card, ask for references, run background checks, etc.
In the email world, the problem is trickier, and that’s what DMARC hopes to solve.
If you don’t have a valid DMARC policy in place for your own domain name, spammers could more easily put on a digital disguise and send emails from your domain name (as though they were you).
So, you’re thinking…
OK, fine.
I wouldn’t want my readers to be scammed.
I would like to protect my identity and my email sending reputation and improve my email deliverability.
Teach me how to create a DMARC record already.
I’m getting there.
Getting good protection is more complex than something you can do in just a few minutes.
But here’s what you should implement as soon as you can to meet the February 1, 2024 deadline.
The “bare minimum” DMARC record
A DMARC policy is just a TXT record (a type of DNS record) associated with your domain name.
The DMARC TXT record must be formatted in a certain way in order to be valid.
The “complete host” (once saved) is ALWAYS _dmarc.yourdomain.com (where yourdomain.com will change, obviously). But most DNS zone editors don’t want you to include your domain name in their DNS record editor. They normally will add it for you.
Its “value” will vary based on the level of protection you want (more on that later), but it MUST start with v=DMARC1;
This partial DMARC record above is NOT complete.
The minimum (complete) value for a valid DMARC record is:
v=DMARC1; p=none;
In plain English, this TXT record says, “I am a valid DMARC record, but I don’t care what you do with email messages (pretending to come) from my domain name. I don’t want you to reject them or quarantine them. Let them all in, please.”
(It also says, “If someone is trying to impersonate me, let those emails flow freely into my readers’ inboxes.”)
If you’re pressed for time, the bare minimum DMARC record is good enough for now so that your emails continue to reach your readers’ inboxes after February 1.
(But you may want to revisit this article later and adjust your DMARC record over time to restrict those free-flowing emails that could come from someone else pretending to be you.)
Step-by-step instructions will be given in a few paragraphs (skip to them here), but first, I want to give a bit more information to authors who’ve never played with DNS records (so they don’t create problems for themselves).
Read on if you’re not the techy type.
Do you currently have a DMARC record?
You don’t want to ADD such a TXT record without first checking if you already have one.
If one already exists, you will need to MODIFY it.
Never add a second DMARC TXT record.
There should only be ONE DMARC policy per domain name.
Here’s how you can check if your domain name already has a DMARC record.
Let’s say your author website is bobsmith.com
You can check if you currently have a DMARC record by going to whatsmydns.net, then enter _dmarc. immediately followed (no space) by your full domain name (including the .com or other), then select TXT and hit “search”.
Look at this screenshot to make sure you understand the format of the DMARC record and how you can search for it.
Replace “bobsmith.com” with your actual domain name.
As shown in the screenshot above, there is no _dmarc record TXT for this domain (hence the X).
The webpage will show you a lot more lines than just the one I included, but you’ll get the gist.
If you already have a DMARC record, you will see its value listed there instead of an X.
So, if you already have one, please follow the instructions below EXCEPT that you will want to EDIT the existing DMARC record.
Again, do NOT create a new one.
only one dmarc policy per domain name, please!
Where to add your basic DMARC record
DNS records can either be modified where you bought your domain name (your domain registrar, which could be NameCheap, GoDaddy, SiteGround, Wix, SquareSpace, etc.) OR where your domain is hosted (your hosting company, which could be SiteGround, NameCheap, GoDaddy, ChemiCloud, Wix, SquareSpace, etc.)
But can you tell me which?
I’m afraid I can’t. Every situation is unique.
In my experience, most authors manage their DNS records through their hosting. So try logging into your hosting account first.
If you don’t see a way to manage your DNS records there, try your domain name registrar.
You could also use the WhatsMyDNS.net service and select the NS (Name Servers) option while entering your domain name. This *may* give you a hint at where the DNS records are managed. Sometimes it won’t, but if it says ns1.siteground.net, then go to SiteGround, as that’s where your DNS records are handled for sure. If you see dns.registrar-servers.com, that’s typically NameCheap, while nsXX.domaincontrol.com is typically GoDaddy. Bluehost is obvious as it would say ns1.bluehost.com. If you see nsxx.serverhostgroup, that’s typically ChemiCloud, etc. There are hundreds of hosting companies, so I can’t list them all.
(If you really can’t find your DNS records anywhere, contact support at your hosting and/or domain name registrar. They should be able to tell you if they manage your DNS records or not.)
How to edit DNS records
Tammi Labrecque of Newsletter Ninja fame has kindly created screenshots to help you with this task.
Click the button below if you want to see how to edit DNS records with Bluehost, ChemiCloud, GoDaddy, SiteGround, WordPress.com.
For DreamHost, see here.
If you don’t see your hosting company above, just Google “hosting-company-name edit DNS records” (obviously, replace the “hosting-company-name” with yours), and Google should be able to help you.
Once you’re logged in and can see your DNS records, you will want to ADD a record of the TXT variety.
Host:
_dmarc
The underscore is important.
Sometimes hosting company have a drop-down menu for the “host” field with @ or www or “other” or “new”. If it’s what you’re seeing, select “other” (or “new”) and then a new area/field should appear where you can type in “_dmarc” (without the quotation marks).
NOTE: If your hosting company doesn’t accept the _dmarc as a valid host, it’s possible you may have to enter _dmarc.yourdomainname.com as the host, but it’s very rare. Always try entering just _dmarc first.
Value:
v=DMARC1; p=none;
TTL:
15 minutes
TTL stands for “Time to Live” so pick the shortest available so you don’t spend hours waiting for your record to propagate. (TTL options vary depending on the provider.)
Propa-what?
I know.
I promised very little techno-talk, but this is important to grasp or else you may get angry (or annoyed or stressed out) for no reason whenever you change any of your DNS records.
Read on, please.
Propagation Time
Whenever you edit DNS records for a domain, the information needs to be sent out and spread out to the rest of the servers across the world.
🎶 Start spreading the news… 🎶
This is called “propagation” and it takes time.
It can vary from a few minutes to 72 hours.
Typically, your DNS records should be updated within 24 hours.
Use the WhatsmyDNS.net tool I mentioned before to check propagation in real time.
If you entered things correctly, over time, more and more servers will display a value (instead of an X or an outdated value). The tool is meant to give you a rough idea; it’s not perfect. A few of the servers listed on that site never seem to display real data and always show red Xs. Ignore those.
Once you start seeing those values populate at most servers with the new information you put in, you know your TXT record was saved correctly.
Just wait a bit more and the DNS records will eventually be live for everyone to see.
Refer to the section here to check to see if your DMARC record is live and propagated.
CONGRATULATIONS!
This ends the section covering the one task you should complete by February 1, 2024.
But read on if you want better protection for your domain name and sending reputation.
Chances are you want to do more than just meet the bare minimum valid DMARC policy because that policy is actually useless for protecting your domain name’s reputation.
A scammer could send emails pretending to be you and your basic DMARC policy says to let them through!
Why improve your DMARC policy?
Your author reputation is an important asset and you should aim to protect your email reputation by not making it so easy for scammers to impersonate you and send nasty messages to your precious readers’ inboxes.
If you don’t want to dedicate any time to this, but still want to get it done, I offer a one-month monitoring service here.
If you would rather spend time (instead of cash) to get this sorted, then read on.
I have done my very best to explain what’s involved, and I’ve linked to FREE tools you can use to help you through the technical difficulties associated with this task.
As I wrote at the very top of the page, emails that you manually send from your email software are NOT the only source of emails that are sent on your behalf.
For most authors, your website and your newsletter provider(s) are also important senders.
Depending on if you’re using free webmail from your hosting or if you’re paying for an email service from Microsoft, Google, Zoho, or other, those companies also send emails on your behalf from their SERVERS, and you WILL want to authenticate those as well, as needed.
I can’t tell you what you’re using.
I don’t read minds.
(I wish!)
Every author does things differently and chances are that you wouldn’t be able to list all of those sources right this minute, even if you are the most organized author out there.
But don’t worry if you don’t recall who you are using.
We can monitor things and find out.
Adding monitoring to a DMARC policy
Remember how I said before that you CANNOT have more than one DMARC TXT record?
I’m reminding you once again because it’s really important.
Scroll back up to the section on how to edit DNS records (if you need a refresher), then log in to your provider, and scroll back down here.
You’re back?
OK.
Make sure you are editing the existing TXT record associated with _dmarc for your main domain.
Click “edit” and then modify the VALUE to ADD the following (after adding a space). There’s no line break, just a “;” followed by a space between the two items.
rua=mailto:email@domain.com; ruf=mailto:email@domain.com
Make sure to change the red bits to an email address that you monitor daily. This will be an ongoing incremental task that we will build on every day.
IMPORTANT NOTE: every “item” in your DMARC policy is separated by a semi-colon, except for the last thing, which has no punctuation at all.
Punctuation is crucial.
The COMPLETE value for your _dmarc TXT record should look something like this, where the email@domain.com (in red below) is changed to be your email address in 2 places.
Don’t include the word “Value:” as it’s not part of it.
Value:
v=DMARC1; p=none; rua=mailto:email@domain.com; ruf=mailto:email@domain.com
So, this is a conservative approach that will continue to let all sorts of emails go through while we refresh our memory about the various places or services our domain could send emails from.
These ongoing monitoring reports will give passing or failing grades to the SPF and DKIM records associated with each sender.
You said little techno-talk!
You lost me.
What are SPF and DKIM?
Glad you asked.
That’s what we’ll discuss next.
Components of a DMARC policy
Getting back to the point of your DMARC policy.
Because the email world can’t check for IDs or run background checks, emails can rely on one (or both) of two records.
Let’s call them validation methods.
Some sources of email can meet both validation methods, but not all.
As I said, Google, Yahoo, and other companies who handle receiving emails can only check your identity against two validation methods:
- SPF: Sender Policy Framework. It’s another type of TXT record associated with your domain name, which is edited via your DNS record. There can only be ONE SPF value for each “host.” So make sure to always EDIT the one you currently have for your domain name instead of adding a new one. (There can be a separate SPF policy for a sub-domain, because it’s a different “host.”)
- DKIM: DomainKeys Identified Mail. Think of DKIM records as a “set” where there’s a public-facing one and a secret one. DKIMs are issued by Google, MailerLite, ActiveCampaign, Microsoft, your hosting, etc. They are also managed via DNS records. (The public side is.) You can have several DKIM records.
So, going back to the fortresses that Google and Yahoo want to offer to their email users…
Here’s how it works, using Yahoo as an example:
When an email from YOUR DOMAIN arrives at the Yahoo fortress door (if one of your newsletter recipients has a yahoo email address, for example), your domain’s DMARC policy instructs Yahoo what to do with the message to check if it’s really FROM you.
Your DMARC policy puts YOU in charge of what Yahoo should do after it checks your SPF and DKIM records.
Will they lower the drawbridge over the moat to let the email message enter past their fortress wall and into that precious Yahoo reader’s inbox?
The SPF and DKIM records serve to instruct Yahoo (and Gmail and other email providers) to perform certain checks when it receives an email.
Those checks involve examining if:
- the email’s “from” address is allowed to send emails on behalf of your domain (SPF record).
- the email has been altered or tampered with during its journey (DKIM record). That’s why there’s a “secret” DKIM from the issuer and a “public” DKIM that you place in your DNS records.
If your email passes ONE of these checks and meets the criteria defined in YOUR DMARC policy, it is considered safe and is allowed into Yahoo’s users’ inboxes.
CLARIFICATION (Added Feb 2, 2024):
A DMARC “pass” only requires passing one of the verification checks (SPF or DKIM), but it must be authenticated AND aligned.
So as long as your SPF is authenticated AND aligned OR if your DKIM is authenticated AND aligned for a specific sender, the email will PASS the DMARC check.
If you can align both SPF and DKIM, it will help your deliverability overall. For example, I’ve noticed that domain alignment in MailerLite (which grants the sender full SPF alignment and DMARC pass) moves messages into my inbox instead of the junk folder.
But some senders are incapable of aligning via SPF (for example), so don’t waste time trying to achieve a pass for both verification methods. For example: Google Calendar will only DMARC align via DKIM. MailChimp will only DMARC align via DKIM.
I hope you’re starting to wrap your mind around the concept of DMARC/SPF/DKIM now.
It’s a lot to take in, but understanding the above will go a long way when we start to fix deliverability problems with the services who send emails on your behalf.
I used Yahoo in the example above, but Gmail and other email providers follow the same process.
I will NOT cover all the options you can enable in your DMARC policy (i.e., DMARC TXT record), but there’s a VERY important variable we still need to cover.
There are only 3 commands that your DMARC policy can use in terms of what you order Yahoo/Gmail/other email providers to do with messages that don’t look like they are coming from you (because they don’t meet the validation checks from the service who sent it on your behalf).
The options are:
- p=none;
- p=quarantine;
- p=reject;
If you’re following along, you’re probably using “p=none;” and it means that you’re asking Yahoo/Gmail/others to let all “successful” + “failed” messages through and deliver them to people’s inboxes.
If your DMARC policy uses “p=quarantine;” instead, Yahoo will send emails that fail SPF/DKIM to Spam. That’s what typically happens when you don’t “authenticate and align” your newsletter provider, for example.
If your DMARC policy uses “p=reject;” instead, Yahoo will NOT ALLOW emails that fail SPF/DKIM and they will bounce. They will disappear, never to be seen by the intended recipient.
With “p=reject” on, and with a message that doesn’t validate SPF/DKIM, readers looking through their junk/spam/promotions will NEVER ever see your message because Yahoo did its job as a fortress caring for its users (and listening to your instructions).
Yahoo did not allow the message through because Yahoo thought the message came from an impersonator.
Let me repeat this because that’s the reason behind my recommended approach of monitoring your outgoing emails for a while BEFORE you improve your protection level and switch to “quarantine” or “reject”.
If you are using a service that sends emails on your behalf and you totally forgot to authenticate it when you got it, and if you crank up your policy to “reject”, then your REAL emails from that sender will NOT be received.
For example, if you’re a GoDaddy customer who is paying for Microsoft email or a SiteGround customer who is paying for Gmail and you never authenticated Microsoft or Gmail as a sender, you could be in trouble.
If your DMARC policy says to “quarantine” or “reject” suspicious emails, Yahoo will assume it’s a suspicious character trying to deceive their email customers, and they won’t let your email through.
… even if it was really you who sent it, from your email service provider you are paying for, and which you’ve been using for years.
That’s why I recommend a monitoring period where we allow ALL emails through, whether or not they pass SPF/DKIM.
During that monitoring period, we can spot problematic senders that are legitimate and fix their SPF and/or DKIM records so they validate.
It’s very possible that some of your legitimate services that email on your behalf don’t email regularly.
For example, if you only send out a newsletter once per quarter, your monitoring reports will not show any errors (or any data at all) if you didn’t send a newsletter during the monitoring period.
Are you following me so far?
Do you understand why “fixing” or “improving” your level of protection with your DMARC policy should be an iterative process?
When the monitoring reports we requested reach our inbox, we will see where we stand with our SPF and DKIM situation.
Those reports are incredibly useful. They will help us pinpoint problems and fix the SPF and/or DKIM records associated with the senders that don’t currently appear to be valid (when they should be).
Those reports will list specific “senders” (those services who email on our behalf), which could be your email program, your website, your newsletter provider, Google, Microsoft, etc.
The reports you signed up for when you added monitoring to your DMARC policy will typically hit your inbox once a day (per company monitoring them, which is Google, Microsoft, Yahoo, any mail provider that saw an email from you).
But you won’t receive your first report(s) right away.
Email companies have to collect data for a while and then aggregate it.
In my experience, I receive reports 2 days AFTER the date for which the data was collected.
So Google, Yahoo, Microsoft, etc. (the big companies that want their users’ inboxes to be like fortresses) will aggregate and summarize those findings daily, then email you that report.
Data will appear in a few days…
WHAT?
I want to fix this now!
I understand that you just want to cross this task off your list.
I’m afraid we would likely forget about a few providers if we did.
But, fortunately, there are ways for us to access data a little faster (and ideally, we can also start to preemptively fix validation errors that our first monitoring reports will show.)
Yes, please!
I’ve got books to write!
You should still wait for those valuable reports and monitor them for a while, but let’s check where we stand RIGHT NOW while we wait for those emails to hit our inbox.
Checking DMARC, SPF, and DKIM
You can check where you stand in terms of DMARC, SPF, and DKIM for your domain overall by using this tool here: Dmarcian Domain Checker.
It’s pretty straightforward. Enter your domain name and hit the button.
A quick note about this free tool.
It will display a scary warning if you only used the bare minimum DMARC record I listed above, with or without the email reports turned on.
But if you read carefully (below the red X, see next screenshot), it will state that the record is valid (but doesn’t protect against spammers pretending to be you).
Both are true.
(And please don’t forget about propagation. If you just changed your DNS records and the info doesn’t seem right, wait for a few hours and then check again.)
If you are seeing SPF or DKIM errors, click on “+ Details” to see if you can figure it out.
Common SPF culprits and solutions for your domain name
You may have more than one SPF TXT record for your domain.
If so, you need to combine them into one.
There can only be one TXT record that begins with v=spf1 per host name.
If you have one SPF TXT record for “@” and one for “yourdomainname.com”, those two hosts are technically the same, so delete one.
“@” is used by some hosting companies to represent the primary domain name associated with your account.
It’s fine to have an SPF record for a sub-domain like “news.yourdomain.com” and a second SPF record for the main domain (yourdomain.com OR @). It’s one TXT record that begins with v=spf1 PER host.
A sub-domain (news.yourdomain.com) vs a domain (yourdomain.com) are two different hosts.
Again, use the Whatsmydns.net service, enter your domain name and select TXT and you will see if there are two sets or just one (or none).
This specific query will also include any Google, Facebook authentication and other TXT records associated with your domain, so disregard those.
Just pay attention to lines that start with “v=spf1”.
There should only be one listing for each entry.
BLUEHOST USERS: the BlueHost DNS editor is one of the worst ones out there, especially now (after they revamped it). If you changed any TXT record, WAIT A FEW HOURS before you try to go back in and change that record again. (If you don’t, you’ll end up with two or more records and a big mess to clean.)
Don’t forget about propagation.
Things take time and you likely won’t see your changes right away.
Common DKIM culprits and solutions for your domain name
If your domain DKIM is not valid, ask your hosting provider to regenerate your DKIM for you.
DKIM is a “set” where one part is secret and you can’t access it.
You only control the “public part” via DNS records. The hosting company places the “secret part” somewhere safe that is out of your control.
You could also google “hosting-company + regenerate DKIM” (where you obviously change your “hosting-company” to use yours) and see what you can find.
For example, with SiteGround, you can do this.
If you need help, start a ticket with your hosting company ( or reach out to customer support by phone or chat) and ask them to regenerate your DKIM for your domain and update your DNS records to match.
If you got both the SPF and DKIM to appear green for your main domain right now…
CONGRATULATIONS!
Right now is a good time to pause and resume later…
OR
You can test some of the services you KNOW you are using, like your email program, your newsletter service, and possibly a website contact form.
(And as a bonus, the interface will also teach you more about DMARC/SPF/DKIM than the simplified version I’m covering here.)
A few things to note before I share the tool.
- Propagation takes time! So if you’ve just changed something in your DNS record, it’s possible the tool will not reflect your latest changes. You can check the propagation tool here first and only run tests AFTER you see that your DMARC policy, SPF record, etc. has been updated (whatever you last changed).
- You will need to send an email FROM THE SERVICE you want to test.
-
- If you’re testing your email program, this is easy. Send a regular email from your email program.
- If you want to test your newsletter service, send a TEST EMAIL to the tool. (You could duplicate an old campaign and send it to just one person, or do that from any of the emails from an automation.) I can’t give exact instructions because they will vary depending on the service you use (MailerLite / ActiveCampaign / etc.) but you can google “how do I send a test campaign in MailerLite” (or other) and the Internet will help.
-
Learn DMARC — free tool
If you go to LearnDMARC.com, you will find a wonderful teacher bot that can help you see what’s going on with your sender validation.
When you visit from your browser, the site will give you a unique address that you can use to email the tool.
(Don’t use the one in the screenshot above, but it will look something like that, bunch of characters ending with @learndmarc.com.)
So boot up your email program and send a blank email to it.
No need for a subject line or any text in the email message. Leave it all blank.
Then return to that browser window where you got the email address from.
Just leave it up, stare at it, and wait.
(Maybe refill your drink.)
It will take a few seconds, or maybe a minute, but your browser window should acknowledge your email and start telling you stuff.
Read the text (don’t worry if you don’t understand all of it), and hit a key (any key) on your keyboard to proceed to the next step when you are prompted to do so.
If you’re in a hurry, there’s a “Fast Forward” button in the top right corner.
Fixing SPF/DKIM Errors
Unfortunately, I can’t provide solutions for every error, but here are some common ones with easy-to-follow instructions on how to fix them:
- Microsoft/Outlook email SPF error: Edit your EXISTING SPF record (don’t add a new SPF record!) and include the following somewhere in the middle of it: include:spf.protection.outlook.com
- Microsoft/Outlook email DKIM error with GoDaddy hosting: Follow these instructions.
- Gmail /GSuite SPF error: Edit your EXISTING SPF record (don’t add a new SPF record!) and include the following somewhere in the middle of it: include:_spf.google.com
- Gsuite or Google Calendar DKIM error: Follow these instructions and be careful to NOT re-generate the keys when you go back to start authenticating.
- MailerLite SPF/DKIM error: Follow the instructions to fully “authenticate” and “align” your domain as per this page. NOTE: WIX users won’t be able to align their domains because of limitations with WIX and its inability to use sub-domain DNS records, which MailerLite uses for “domain alignment”. If you use WIX and MailerLite, you will want to vote on this feature here.
Newsletter errors?
I recommend you follow your newsletter provider’s authentication instructions.
Or even better, look at what the Newsletter Ninja created and was kind enough to share with me (and everyone reading this).
Click the button below if you want to see how to authenticate and align your newsletter provider with screenshots from Tammi Labrecque.
Her article covers “Classic” MailerLite, New MailerLite, ConvertKit, and Drip.
If the instructions mention a TXT record having to do with SPF, there can only be one per domain name. So be careful if you already have one.
Just edit the existing TXT record that starts with v=spf1 … because there can only be one TXT record per host that begins with v=spf1!
But it’s okay to create a new TXT record for a sub-domain that also begins with v=spf1. The sub-domain is a different host from the domain. One per host.
Other newsletter providers use CNAME or other types of DNS records (instead of an SPF TXT record entry) so just check with your newsletter provider if Tammi didn’t cover it in her extensive instructions.
For any other errors…
You can try your luck with Google.
And if you have a Shopify store, don’t forget to authenticate it as well!!!
And Klaviyo if you also use that service.
So, you can try to fix the errors that the LearnDMARC.com tool points out, or you can wait until your monitoring reports start coming in. Those reports contain helpful tips that could give you the answer you were looking for.
In the next section, I’ll explain all of that.
So go treat yourself to something nice as you wait for those monitoring emails to come in (probably tomorrow or the next day).
Bookmark this page and make a note to return to “The incremental DMARC protection approach” once you get those emails. (There’s a table of contents with quick links at the top.)
The incremental DMARC protection approach
Welcome back.
As I mentioned before, I highly recommend improving your DMARC policy over time instead of overnight.
By monitoring the outgoing emails related to your domain name , you will refresh your memory about what you may have set up for your author business weeks/months/years ago.
My recommended approach allows for letting (potentially suspicious) emails go through to your readers’ inboxes while we monitor all outgoing emails and, over time, refine and improve the SPF and DKIM records for all valid sources of emails.
I will explain how you can read those code-heavy reports without having to know code at all.
But first…
Important details to keep in mind about those reports:
- They can only report on the emails they see arriving in their users’ inboxes. (So if your domain doesn’t send emails, you won’t get any reports.)
- If you don’t have emails being sent to Yahoo email addresses, you won’t receive reports from Yahoo. Ditto from Google, Microsoft, etc. (So you may not receive reports from all the big companies every day.)
- The data is accumulated and sent to you AFTER the fact. The date for data collection is included in those reports, so if you’ve been making modifications to your SPF and DKIM (or other DNS records), please keep in mind that the reports will often reflect OUTDATED records. Don’t undo your tweaks just yet. Track the changes you’ve made and CHOOSE TO IGNORE some results for about 3-4 days if you’ve made adjustments.
So I highly recommend getting a pen and paper (or starting a spreadsheet) to make notes of your DNS changes (what and when) so that you can choose to disregard a reported error if you know you’ve already fixed the issue being reported.
I highly recommend you track and log any adjustments to your SPF TXT records what you added and WHEN) and if you set up a new DKIM (from where and WHEN). You’ll likely want to keep track of your start and end date for monitoring and changes made to your DMARC policy as well.
The spreadsheets above are a starting point and contain 3 tabs, with some sample data so you see one way to track things.
You don’t have to use it as-is.
Do whatever works for you.
I’m repeating myself here, but I don’t want you to get mad and give up, thinking you didn’t fix the problem when, in fact, you did.
DELAYS WILL HAPPEN, ALWAYS.
If you make a change, give your monitoring reports 3 to 4 days before concluding that you didn’t fix the issue.
Delays will happen because:
- Propagation: If you updated your SPF record at noon on Monday, it’s possible that the record won’t be “live” for everyone to see until noon on Tuesday. (Propagation can take anywhere from a few minutes to up to 72 hours.)
- Monitoring reports are outdated by nature. Each report includes the start and end dates and times for the data they are reporting on. Cross-reference those dates with your notes to see WHEN you made changes (and don’t forget to factor in propagation).
- Time zone difference. Unless you live in the UTC time zone (Greenwich, UK), the reports will mention times that won’t match your time zone, so there are a few hours of delay there as well.
So, with all of that in mind, let’s look at our first monitoring report.
In the screenshot below, you see one of the many emails I got for one of my domains. If you read the text, you’ll see important info:
- It’s from Outlook, so that means at least one message was sent from my domain name to at least one “outlook/Microsoft” user, which could be hotmail, outlook, paid Microsoft 365 account associated with any domain name, etc.
- It only covers data collected between Jan 17 and Jan 18, UTC (which isn’t my time zone), so I will keep these dates in mind when I compare my notes and will probably choose to ignore failures if I’ve already made changes to fix it.
You COULD open the file, but chances are you won’t know what it says. It’s a zipped file that contains an .XML file.
It will be pure gibberish to most authors.
Here comes our final free tool to help us “read” those reports:
https://us.dmarcian.com/xml-to-human-converter/
Drag and drop the zipped file(s) attached to your email(s) into the area, then click “upload files.”
A few seconds later, you should be able to see “view report” next to each of the file you uploaded.
In my experience, this free tool works beautifully for most monitoring reports, but there are email companies out there who send out XML files in an invalid format… So those you may have to open and try to decipher… Sorry.
Also, it only lets you review a limited number of reports during a given time, so if you stay on top of them and check the reports daily, you shouldn’t run into this issue. I haven’t paid attention to the exact number, but around 10-12 works and you can run into problems around 15+ reports.
When you view the report, you’ll see a pretty graph with lots of text.
READ everything in this report.
Especially the date or “COVERAGE.”
On the right, you’ll see what your DMARC policy was DURING THAT COVERAGE window. (You may have changed it since. Remember that the data is outdated.)
You’ll see “pass” or “failure” in a nice color code for DMARC overall (whether the email passed overall) and then the SPF and DKIM specifically.
For DMARC to “validate overall”, either SPF or DMARC needs to “pass” DMARC.
Again, keep in mind the COVERAGE date and when you modified your SPF/DKIM before deciding to tweak your records once more.
Monitoring all senders
Note how each “sender” appears on its own line.
The screenshot above was taken from an author site hosted on SiteGround. The author uses MailerLite as a newsletter provider and pays for GSuite email and uses the Calendar feature associated with the author email address to email calendar invitations.
If you’re hosted on BlueHost, use ActiveCampaign and use Microsoft 365 email, you wouldn’t be seeing the same senders.
But I’m hosted on SiteGround and use MailerLite and I don’t see those lines in my report!
What the heck?
You may have skimmed through something important I wrote earlier.
In order for you to receive monitoring reports from Microsoft (as an example) and for that monitoring report to include lines about MailerLite + hosting company + Google, then at least ONE email message had to be sent to at least ONE Microsoft user (because we’re looking at an aggregate report from Microsoft in this example) from EACH of those services you want to have in your report during the COVERAGE period listed in the report.
So, if you’re not getting any monitoring reports or if your monitoring reports doesn’t include MailerLite for example, it’s because NO EMAILS were sent to any Google users (or Yahoo/Microsoft, depending on the report source) during the COVERAGE period listed on the report.
Capiche?
I understand you may not use those services every day.
If you don’t want to manually trigger those emails, just keep monitoring for longer.
But if you have other things to do and want to sort this out sooner rather than later, I recommend you MANUALLY SEND EMAILS from all of your services to see if they currently pass validation. (So you can improve your DMARC policy to do “quarantine” or possibly even “reject” if you’re confident with what you’ve done.)
How to manually trigger an email from a certain service
I recommend using your personal Gmail/Gsuite or Ymail or Hotmail/Outlook/Microsoft as the recipient for those test emails.
I’m saying this because Google/Yahoo/Microsoft are very good at sending valid aggregate reports on time and you can easily create a free email account with one of them if you don’t already have such an account.
So, send a short email from all/any of your services that send on your behalf TO that personal Gmail/Yahoo/Hotmail address that you own.
That’s it.
Send yourself a test campaign from your newsletter provider (to test MailerLite/other).
Email yourself (to test either your hosting webmail or Microsoft, Zoho, or Gmail, whatever you use).
Temporarily change your contact form on your website to send an email to that personal email instead of whatever it does normally. (Testing the contact form should trigger the email from your server/hosting company.)
If you have a store on Shopify or WooCommerce, place an order.
If you use other services like Google Calendar or anything else that is related to your domain name and that sends email, use it and send yourself a test email.
That way:
- Only YOU will get your extra test emails. You won’t annoy readers or newsletter subscribers with an extra email you didn’t want to send.
- If there is a problem, you won’t care if the email goes to spam or bounces.
- No matter if it bounced or went to spam, the monitoring report from Yahoo (or Google or Microsoft, whoever it is you use for your personal email that you’re testing with) will be triggered and you should receive that monitoring report a couple of days later.
THEN WAIT.
(The reports will appear a couple of days after your test emails went out.)
Once you get your report, drag and drop it into the human-readable XML tool, then view your results.
Click on the fancy “+” signs on the left to expand and view more data.
Click on the blue “Guide” link and little pop-ups will appear, which often include links that should help you fix your SPF and DKIM issues.
Depending on the emails that were sent, you may also see more than just the DMARC tab.
SOME (but not ALL) of your reports will have information in more than just the DMARC tab.
Again, it depends on what Google saw come in during the COVERAGE period that was associated with your domain name.
See below for an example, with “forwarders” + “Threat/Unknown” senders being reported.
You’ll need to use your judgement (and possibly a little help from Mr. Google if you see a sender that you don’t recognize).
Some of the “threats” may be false positive.
If you see senders who shouldn’t send, it might be time to beef up your DMARC policy and send those non-valid senders to Quarantine/Spam (or possibly Reject/Bounce if you’re certain you’ve validated all your real senders).
How long should you monitor emails?
You should do this over an extended period.
How long depends on you.
How many emails does your domain actually send?
How often?
Would your services only send emails once a week/month/year?
Are you confident you’ve seen and tested all of those services that email on your behalf?
At some point, those daily reports will bug even the most patient person among us. We have better things to do than constantly monitor them, right? Those books won’t write themselves if we spend hours monitoring and tweaking our DMARC policy.
I personally would recommend monitoring for a minimum of one week, and ideally one month, if you have the mental bandwidth for it.
So I highly recommend getting a pen and paper (or starting a spreadsheet) to make notes of your DNS changes (what + when) so that you can choose to disregard a reported error if you know you’ve already fixed the issue being reported. (Then wait a few more days and if you fixed it for real, those reports should show the correctly aligned (pass) grade.)
The first entry should be [today’s date]: adjust my DMARC to be [whatever you did]. Or I changed my SPF record to include XYZ.
If you don’t want to do this yourself but understand the value of it, you can hire me to monitor your DMARC reports for a month, and I’ll help you validate those valid senders and improve your DMARC policy.
