How do you send emails from your business domain name? Maybe you use Google Workspace for your business emails, Mailerlite for your marketing emails, and an SMTP service for contact or order forms from your business website. But… how do you know that they’re all set up and working as they should be? Are your emails going to spam?
You’ve either sorted the correct settings for all of these providers, including SPF, DKIM, and CNAME entries to ensure all are correct. The next step is to see whether all of these are correctly configured with a weekly DMARC report (after testing). This report ensures you’re keeping track of emails being sent from your business domain, and that the large email service providers (Gmail, Hotmail, Apple Mail, and Yahoo) are seeing the same things you are, and they’re seeing your emails as legitimate.
DMARC also protects your domain emails from spammers/scammers spoofing your emails trying to convince customers/clients that the emails are from you. If you’re properly authenticating all of your business emails, then large email service providers will quickly detect the spammers/scammers and block their emails completely.
DMARC reports help you understand all of the above.
TL;DR?
If you don’t have DMARC set up correctly — providing you with information about SPF alignment & DKIM authentication — then your emails could end up in spam/junk folder or be rejected, and you wouldn’t even know! Think it all doesn’t apply to you because you don’t send a large amount of emails? Think again. Everyone is affected. See our prices here.
What is DMARC
DMARC is a standard that includes reporting to prevent spammers/scammers from passing their emails off as being from your domain. Have you ever seen a rogue email that looks like it’s from your bank, PayPal or another financial institution and it doesn’t look quite right? DMARC (Domain-based Message Authentication, Reporting & Conformance) aims to check and provide information to email providers that the emails you are sending are legitimate (authenticating and aligning) and that any others someone else sends aren’t.
DMARC is free to use and available to anyone who has a domain name and is sending emails, regardless of the volume of email sent and the services used to send them. DMARC is an open policy framework, just like sending an email, so it’s simple (though not super easy) to set up and manage the flow of emails from your business.
DMARC is a DNS TXT record that lets you tell email receivers how to handle messages that fail SPF and DKIM checks (Cloudflare)
Why implement DMARC?
Why should you implement DMARC for your business domain emails?
DMARC is an essential tool to use when your business relies on email. Here’s why:
- Don’t end up in spam — you can monitor emails sent from your email account or on your behalf from another provider (e.g., email marketing). Identifying whether SPF records are aligned and DKIM is authenticating, you can identify any holes in your set up and prevent your emails going into the spam/junk mail folder.
- Protect your brand — Show email service providers (like Gmail, Hotmail & Yahoo) that your emails are legitimate and any others sent by scammers are spoofs and should be rejected.
- Security — Prevent customers/clients from interacting with a branded email that isn’t from your business but appears to be.
- Sleep well — Know that when it comes to emails from your organisation, you’re protected and you’ll be able to know of any issues by browsing through the weekly DMARC reports.
How does DMARC work?
DMARC helps with the deliverability of your business emails to people’s email inboxes. This comprises two main elements: SPF and DKIM.
DKIM (DomainKeys Identified Mail)
DKIM is a DNS entry that is used to authenticate the emails you’re sending to a person’s email inbox as having come from you. Think of it like a passcode sent to your phone (or using a 2FA app) to sign into your banking app/account: there are public and private keys.
When your email is received, the receiving server requests your DKIM authentication records, the public key that sits on your DNS records. This confirms that the email being received is legitimate as the keys contained in your DNS records match the keys included in the email. Once the mail server identifies they match, it authenticates and gives you a big green checkmark, indicating that your email is coming from a valid source and your domain is validated. It also ensures that the email hasn’t been altered along the way.
This happens with each email sent from, for example, Google Workspace, with the email having a private key in the email header that will then authenticate with the public key in your DNS records (see an example below). This is the same cryptography used with SSL certificates (https://) that ensure your website is secure when important or sensitive information is transmitted (for example, card details or contact form submissions).
An example of a Google Workspace (formerly GSuite and Google Apps) DKIM record:
In this example, you’ll see it says “not authenticating” at the top. Once you enter the record with your DNS provider and publish it, after 48 hours, you go back to this page and select “START AUTHENTICATION.” The top line’s status should then switch to “Authenticating email,” which means DKIM has been fully set up for your Google Workspace account. Other business email service providers have similar processes for adding DKIM to your DNS records and authenticating outgoing emails.
This is why DKIM is crucial for your domain emails (whether business emails or marketing emails) because they authenticate via DKIM and need to pass DMARC checks to be seen as legitimate.
SPF (Sender Policy Framework)
SPF has been in place for several years and was one of the first ways that email service providers started to prevent spoof emails from reaching inboxes. It’s a way for large email service providers (Gmail, Hotmail, Yahoo, etc) to check whether the mail server sending the email to them is acting on your behalf. This is also why an SPF record should include all records for all of the service providers you use (business email, SMTP for your website, and marketing email provider, etc).
The above record is an example of an SPF record in the DNS settings for a domain. You should only have ONE of these in your DNS records, as multiple may cause an email service provider to choose a random one or disregard all of them.
The elements to it are:
- v=spf1 — this is the signifier that the text (TXT) record is for SPF
- a — states that if the sending IP matches the A record for the domain, then pass SPF
- mx — states that if the sending IP matches the MX records (receiving email host) then pass SPF
- include:_spf.google.com — match all IPs that Google includes for its SPF records (if you’re using Google Workspace, then you’ll need this)
- include:_spf.mlsend.com — match all IPs that Mailerlite includes for its SPF records (if you’re using Mailerlite as your email marketing platform)
- ~all — a softfail on all emails in case they don’t pass SPF. This means emails will probably go to the spam/junk folder if they do not pass SPF checks.
SPF is still an important element of ensuring emails received by the incoming mail server are legitimately being sent on your behalf, as you might be using a helpdesk software (Helpscout, Zendesk, etc) or an email marketing platform (like Mailerlite, Klaviyo, Brevo or HubSpot) to send emails. These will all use SPF and need to pass all of the checks (something that is especially important for third-party sending due to how forwarded emails are treated).
How do you authenticate with DKIM and have SPF align so that DMARC passes?
You do this by setting up both records correctly in your DNS records. Have one SPF record that aligns correctly and has all of the entries included for all of the service providers you use to send business emails (e.g., Google Workspace or Microsoft 365) and any other service provider (such as an email marketing platform or a helpdesk).
You’ll then generate a DMARC record for your domain that advises all email service providers (like Gmail, Hotmail & Yahoo) where to send the information they have summarised for incoming emails sent from your domain. As long as this is configured correctly, you can use a DMARC report service to summarise XML markup data. If you just put your email address as the DMARC reports address, you’ll receive a load of XML code attached to email reports.
In its basic form, the DMARC record sets out what an incoming mail server should do with emails from your domain.com and how to authenticate against DKIM and align with SPF. If they both fail (and thus DMARC fails), any emails will generally end up either in the spam folder or in the black hole of emails (not rejected and not delivered either). If you don’t have a DMARC reporting set up, then you’ll never know. Want our help? Check out our pricing.
DMARC Reports
These are reports sent to you as a domain name admin/owner by large email service providers (think Gmail, Hotmail, Yahoo, etc). They contain information (usually in XML, a markup language) about how the system has dealt with emails from your domain name.
They include the service providers and the percentage of emails that passed DMARC, as well as the percentage that passed DKIM authentication and were SPF aligned.
There are two services we use and recommend: Cloudflare DMARC management or Postmark’s free weekly DMARC emails. Both offer a simple way to monitor your DMARC reports, with Cloudflare offering an easy setup (they’ll add your DMARC record to your DNS settings directly as long as your DNS is with them) and a dashboard to view everything. Postmark offers a summary email every week, but this requires you to make some manual changes to your DNS records. However, the setup is a step-by-step guide, and their checker tool will ensure everything is set up correctly.
There is also a paid option: DMARC Digests. This is good if you want extended information or if you look after different domains/brands.
Our choice? Postmark’s free weekly DMARC emails. They’re easy to view and provide a nice summary of the information.
How to set up DMARC Reports
To produce a summary report every week that gets sent straight to your email, we’ll use Postmark’s DMARC reports feature. It’s simple to set up and integrate.
1. Generate a DMARC record
Head to this page, enter the email address you want to receive reports to and the domain you want to monitor (note: you need access to the DNS records for the domain to receive the reports, so you can’t receive reports for just any domain). When choosing an email address, this can be your primary email address: Postmark will give you an email address that will receive the XML info, format it and then send the information to you.
Here’s an example of a DMARC TXT record from Postmark:
Here’s a breakdown of what the information means for this record:
- v=DMARC1; — this signifies the record is for DMARC analysis and processing
- p=none; — this sets out your policy of action that you want a mail server to do upon seeing an email that fails DMARC: none means take no action, quarantine means place the email in the junk/spam folder, and reject means delete the email and don’t deliver it at all.
- pct=100; — percentage of the number of emails from your domain to which this policy applies
- rua=mailto:[email protected] — the email address that DMARC reports should be sent to (this should be the supplied Postmark email they give you).
- sp=none; — subdomain policy set to none (take no action); if you have emails from subdomains, then this may be different.
- aspf=r; — SPF strictness conditions are set to relaxed.
A note on p=none;. This is a placeholder and should be moved to quarantine once you’re sure the record entry is correct, and you’ve started to receive DMARC reports. You should then monitor reports for the next 4 to 8 weeks. We take care of this using our optional DMARC 60-day monitoring add-on for our DNS Sorted package.
2. Add the record to your DNS
Once you have the record in the above screenshot, you’ll head to your DNS dashboard. Sometimes this will be where your domain is registered, with your hosting company, or an external DNS provider like Cloudflare.
- Head to your DNS provider and click to add a new record.
- Select TXT.
- In the host or name field (first one), you add _dmarc (in some systems, you might need to add _dmarc.mydomain.com).
- Add the DMARC record Postmark gave you (as shown above; going from v= to the ; at the very end).
- Leave TTL to default and click save.
- Go to MX Toolbox to check that your DMARC entry is correct. Type in your root domain (e.g., mydomain.com) and everything should show green.
If you’re unsure about the above or you don’t usually edit your DNS records, you can easily choose our DNS Sorted package here (we’d recommend 60-day DMARC monitoring to ensure we oversee the initial monitoring process), or you can ask your on-hand techie or hosting company to add the record for you.
3. Ensure all services you use are using DKIM and SPF
You should then review and check that your DKIM records are in your DNS and the single SPF record has all of the services you’re using for your domain. For example, if you have a WordPress website, business emails on Google and use Mailerlite to send marketing emails, you would have three entries for DKIM and SPF: one for your Google Workspace account, one for the SMTP service for contact forms etc on the website (sometimes people use their hosting company by default), and the Mailerlite ones.
You should ensure all of these services (and maybe others) are correctly entered into your DNS records, as the DMARC entry will ask a receiving mail server to check these records. If the record isn’t there, then your email(s) may end up going to spam or be rejected completely.
4. When to start quarantine and move away from p=none
Historically, using p=none; has been a standard way of setting up the quarantine protocol for a domain’s DMARC record. Most providers (including Postmark) provide this, and many email marketing services recommend keeping the p= value as none. However, in 2025, we’ve started to see large email service providers (Gmail, Hotmail, Yahoo) being stricter with this entry, sometimes treating the “none” value as not existing, meaning they’ll choose to place the emails in spam or junk mail folders even when everything passes all of the checks!
- p=none — Monitor only, take no action. A good placeholder.
- p=quarantine — If an email fails DMARC checks, send to spam/junk mail
- p=reject — If an email fails DMARC checks, it is deleted or rejected to sender
Our advice? Set up the record, ensure it’s correct, receive your first DMARC report, then move to quarantine. If you want, you can change the pct value so the record restricts checks to a percentage of emails and then increase it over the first few weeks when reports show everything is good.
This part of the whole DMARC and reporting secnario can become a little technical, which is why we suggest you use our DNS Sorted package with the 60-day DMARC monitoring add-on so that we can check all of your DNS records, make the appropriate changes, and ensure at least 6-8 weeks of monitoring passes before we hand everything back over to you.
5. Monitoring DMARC Reports
You want to ensure the emails you’re sending from your domain (or those sent out on your behalf) are passing all DMARC checks.
A report contains checks for different services sending emails and will show the percentage of emails that passed both DKIM authentication and SPF alignment.
The above screenshot is a real report from Postmark showing that 301 emails were processed in this particular weekly period (based on feedback, XML markup data, and from the different email service providers), with 0% being not aligned/authenticated. If the checks failed, it would clearly show you in red. If that happens, it’s important to investigate why. Please note: 100% of all emails sent, for example, won’t be in the total number you sent as some providers don’t send DMARC reports.
While some information has been removed for privacy, if you are using different services to send emails for your domain name (e.g., Google Workspace for business emails, SMTP for website contact form emails, and Mailerlite for email marketing), then all of these services will be listed separately. You’ll be able to see which services are 100% aligned and which are not.
If you’re using our DMARC monitoring service, then we’ll confirm with screenshots that the checks are 100% aligned in the first couple of weeks, and once again on handover.
You want to identify that all service providers sending email on behalf of your domain are properly DKIM authenticated and SPF aligned.
We set up your DMARC reports as part of our DNS Sorted package. See the pricing here.
Frequently Asked Questions
Here are some frequent questions around DMARC (including SPF records alignment and DKIM authentication) we often get asked:
How long does DMARC take to propagate?
It takes around 24-48 hours for DMARC changes to fully propagate across the globe, but in some cases it can be within a few minutes.
You can discover that some providers (like even Google Workspace) can take a lot longer to review your changes fully. This is usually because they want all of the changes to have taken effect, resulting in a mismatch in verification of your DKIM records.
Which should I prioritize first: SPF, DKIM, or DMARC?
If we were writing this guide a year or two ago, we’d say prioritize SPF and DMARC. This would be a good decision to help you reach inboxes and not end up in spam/junk folders. However, with us now being in 2025, email service providers (the likes of Gmail, Outlook & Yahoo) are much stricter with domain-based emails entering their environment. This means all three should be a priority as they work in partnership with one another: DMARC is the record that informs the receiving mail server what to do with your emails if they fail checks. SPF and DKIM guide the checks to help pass DMARC. If you rely on email for your business or organization, then we believe all three are a must.
Do all email service providers support DMARC?
Not exactly. Some SMTP providers and email marketing providers will, instead of providing you with DKIM and SPF records, give you a CNAME record so that the return-path of the emails sent by them (on your behalf) identify as a legitimate sender. This is a rather technical process, but it’ll make sense when you’re taking all of the records from the different service providers you use, and they ask you to add a CNAME record. It’s their way of satisfying DMARC compliance.
Why do I see forwarded emails pass DKIM but fail SPF?
When an email is forwarded to another person from the original recipient, there is a new entity sending the email (the forwarder), and so any checks performed will fail SPF. This isn’t an issue, since the receiving mail server is aware of this, which is why DKIM authentication is also important.
As DKIM authenticates during DMARC checks on the forwarded email, the email won’t go to spam or junk regardless of your DMARC record settings, since DMARC has passed using DKIM.
What about catchall email addresses and emails sent to alias addresses?
This is where it gets a little tricky, with catchall emails being similar to forwarded emails. So, if you do have a catchall email address and you’re doing a quick check of the headers in Google Workspace, SPF will always fail if you’re not sending the email to the main email address on the individual account.
Why p=none is not a good move in the long-term
From early 2025, we started to see some issues with large email service providers and their treatment of the p=none; record. Lots of them don’t like spam (who does, right?), and they don’t like DMARC records to be lazy and/or ambiguous. So, they’ve started to treat domain-based emails with a p=none; entry as having no entry at all (thus ignoring it completely). This means emails can end up in the spam/junk mail folder even if all of your records are correct: p=none; causes the emails to end up in spam!
Should I use DMARC for domains that don’t send email?
Yes. Even if you don’t send email from a domain that you own, you should still have a published DMARC record. You can set the policy field to reject so that a spammer/scammer can’t spoof emails from you.
Can DMARC stop phishing or email spoofing?
No. It won’t prevent phishing emails, but it should protect you against spoofing. Phishing emails are usually linked to the sender getting information from the receiver to then take credit out in their name or get them to send money. Spoofing is seen as passing one email sent as being from another domain (even if seen as similar) and convincing the recipient that the email is from the business they thought it was from, not the scammer.
Should I use a subdomain policy?
Yes, if you send email from a subdomain email address. If you’re using a subdomain for email marketing emails, e.g., [email protected], then you should setup the sp= rules in your DMARC information. If you’re not sure how to do this, feel free to contact us.
Once I’ve done all of the DKIM, SPF, and DMARC entries, I can relax?
Well, maybe. If we were auditing all of your DNS records, correcting the current ones, and adding all of the ones you need then we’d be testing your ecommerce/website order or contact emails, testing business emails, and testing any helpdesk or email marketing emails (as long as you request us to do that via the add-ons for your order). You can also do these tests yourself (we list some of the providers we use in our tools page) and then make the required changes. For us, this is a necessary step to ensure your emails are fully authenticated/aligned without waiting another week or so for a DMARC report.
How We Help
Here at DNS Ninjas, we take all the hassle out of configuring DMARC: we do it every day and are well-versed in various platforms and systems.
While it adds to the total amount paid, we’d urge you to choose our DMARC monitoring service. We’ll monitor your reports and make any adjustments required. We’ll also then, with your agreement, change your p=none record in your DMARC to quarantine (or reject, depending on how long we’re monitoring for) to ensure the best protection for your business emails and your sender reputation with email service providers.
