Resources / DMARC and mail
From the applications you use to DMARC pass or fail
A business sends mail from more places than anybody remembers. Each place is an application, each application uses a sending service, and each service's mail either passes DMARC or fails it. Before a domain can move its DMARC policy to reject, every one of those has to pass, or real mail is refused along with the forgeries.
From an application to a DMARC result
1 · Application
Something in your business that sends mail: the newsletter, the invoices, the password resets, the contact form, the people in your sales team.
2 · Sender
The service that actually hands the mail to the internet: Google Workspace, Microsoft 365, Mailchimp, Stripe, SendGrid, your website host.
3 · Checks
The receiving server checks SPF against the return path, and DKIM against the signature. Each one passes or fails for a domain.
4 · DMARC
Passes when one of the checks passes for your domain, the one in the From address. Otherwise it fails, and your policy says what happens.
Pass is not the same as aligned
SPF and DKIM each prove a domain, and it is often not yours. SPF proves the domain in the return path, the hidden address that bounces go back to. Most services use their own there, so SPF passes for the service. DKIM proves the domain in the signature, and a service signs with its own domain until you give it yours. DMARC counts a check only when the domain it proved matches the From address. A relaxed match (the default) accepts any name under your domain, such as mail.yourdomain.com. A strict match accepts only the exact name.
That is why an include: in your SPF record does not make a service pass DMARC. The include lets the service's servers send, but the service puts its own domain in the return path, and SPF passes for that domain and not for yours.
One domain, four applications
| Application | Sender | SPF | DKIM | DMARC |
|---|---|---|---|---|
| Staff mail | Google Workspace | Pass, yourdomain.com | Pass, yourdomain.com | Pass |
| Newsletter | Mailchimp | Pass, mcsv.net | Pass, mcsv.net | FailTurn on custom DKIM in Mailchimp. It gives two CNAME records to publish. |
| Invoices | Billing service | Pass, its own domain | Pass, yourdomain.com | Pass |
| Contact form | Website host | Fail | None | FailSend the form through a service that signs as you, or add the host and set up DKIM there. |
Make each sender pass
There are two ways, and DKIM is the better one.
- Sign with your domain (DKIM). The service gives you a key to publish, usually as one or two CNAME records under _domainkey. Its mail then carries a signature for your domain. A signature survives forwarding, so this is the one to set up first.
- Send from your domain (SPF). Some services let you set the return path to a name under your domain, such as bounce.yourdomain.com. SPF then passes for your domain. Forwarding breaks it: the forwarder's server is not in your record.
A service that can do neither cannot send as your domain once you are at reject. Send its mail from a subdomain with a policy of its own, or move that application to a service that can sign.
Moving to reject without losing mail
- Publish p=none with an rua= address, and read the aggregate reports for two to four weeks. Every source that sends as you shows up, including the ones nobody listed.
- Put each source under an application and a sender. Fix each sender of yours so it signs with your domain. Write down the ones you do not recognize: they are the reason for the policy.
- Move to p=quarantine. If you are unsure, apply it to part of the mail with pct= and raise it as the reports stay clean.
- Move to p=reject. Keep reading the reports. A new tool that somebody signs up for next year is a new sender that fails until it is set up.
See your senders
The DMARC checker names the services your SPF record allows, looks for their DKIM keys, and says which can pass at your policy. It reads DNS, so it shows who may send. The aggregate reports (what is in one) show who does.