A local cycling club had sent a monthly newsletter from its own domain for years: route changes, a ride calendar, a photograph of whoever fell in the ditch at the last social. It went out from an address at the club's domain, through the mail service its previous secretary had set up, and members read it over breakfast on the first Sunday of the month.
The new committee decided the old tool was clumsy and switched to a modern mailing service with templates and sign-up forms. The first issue went out on schedule. By the following week, members were saying they had not received it. Some had found it in junk after a search. Others never saw it at all. The club's open rate, which had always been healthy, dropped by more than half.
What members noticed first
The symptoms were uneven, which made the problem harder to see. Members using one large mailbox provider reported that the newsletter went straight to junk. Those on a second provider received it in the inbox with a small warning banner. People on a smaller regional provider got nothing, and no bounce reached the club either. A couple of members forwarding to a work account saw it rejected outright.
The committee tried the obvious fixes. They rewrote the subject line to remove exclamation marks, reduced the number of images, and asked members to add the club to their address books. These help at the margin, but none of them touches the real issue, and the next issue was no better.
The treasurer, who looked after the domain and the website, did what any support engineer would do. She asked what the receiving servers were being told about the mail.
How a receiving server judges a message
When a message arrives claiming to come from [email protected], the receiving server cannot see who really sent it. It has three questions it can check, all of them answered by DNS records the domain owner publishes.
- SPF: was the sending server's address on the list of senders the domain authorises?
- DKIM: does the message carry a cryptographic signature that matches a public key published by the domain?
- DMARC: does the domain say what to do when those checks fail, and do the checks relate to the visible From address?
Mail that fails or lacks all three looks exactly like a forgery. A mailbox provider has to assume the worst, since forged mail from familiar names is how phishing works.
What the club's records said
The treasurer looked at the domain's DNS and found this, which she pasted into a note:
example.com. TXT "v=spf1 include:oldmailer.example.net ~all"
(no DKIM record for the new service)
(no _dmarc record)The SPF record authorised only the previous provider. The new service sent mail from its own servers, whose addresses were not on the list. The record ended with ~all, a soft-fail, so a mismatch meant "suspicious" instead of "reject". That setting is why mail went to spam rather than vanishing for everyone. There was no DKIM key, so the messages carried no signature. And with no DMARC record, receivers had no policy from the domain and made up their own.
The fix, step by step
The work took one evening, with a calm DNS control panel and a cup of tea.
- SPF. She added the new service's include to the existing record rather than creating a second one, because a domain must publish only one SPF record:
v=spf1 include:oldmailer.example.net include:mail.newsender.example ~all. The SPF builder helps assemble this and warns when the lookup count nears the limit of ten. - DKIM. The service generated a key pair and showed a record to publish, usually a CNAME or a TXT at a name like
sel1._domainkey.example.com. She copied it exactly and then pressed the service's verify button. - DMARC. She published a record in monitoring mode, so nothing would be rejected while the club learned what was sending:
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]" - Test. She sent the next issue to a few addresses on different providers and looked at the message headers for
spf=pass,dkim=passanddmarc=pass.
The DMARC builder produces the record and explains the policies. The key point is the alignment: the domain in the visible From address has to match the domain that passed SPF or DKIM. Setting up the service with its own signing domain would pass DKIM for the service and still fail DMARC for the club.
Reading the proof in the headers
Before and after the fix, the same test told the story. The treasurer sent the newsletter to a personal mailbox and opened the full headers. Before, the authentication line looked something like this:
Authentication-Results: mx.example.net;
spf=softfail smtp.mailfrom=bounce.newsender.example;
dkim=none;
dmarc=fail header.from=example.comAfter the changes it read spf=pass, dkim=pass header.d=example.com and dmarc=pass. The details matter. SPF is checked against the envelope sender, the hidden return address, which for many bulk services is a domain belonging to the service. That is why the SPF pass on its own does not satisfy DMARC for the club: the return domain does not match the visible From. The DKIM signature, made with the club's own domain in the signing field, is what provides the match.
If your service offers a custom return-path or bounce domain, setting it up is a worthwhile extra, usually one more CNAME record. It makes SPF align too, so DMARC has two ways to pass instead of one.
The second sender nobody remembered
Within a few days of publishing the DMARC record, aggregate reports began arriving by email as compressed XML files. They are not pleasant to read, but a free report viewer turns them into a table of sending sources: the address, the volume, and whether SPF and DKIM passed.
| Source (illustrative) | Volume | SPF | DKIM | Meaning |
|---|---|---|---|---|
| New mailing service | Monthly bulk | pass | pass | Fixed, as intended |
| Club mail server | A few a day | pass | none | Normal mail, needs a DKIM key |
| Ticketing system | Weekly | fail | none | A forgotten sender |
The surprise was the third row. A ride-booking form on the club's website, set up by a volunteer years earlier, was sending confirmation emails as the club's domain from the web server. They had been landing in spam for months. Nobody had complained, because people assumed that their confirmation had not been sent, and booked by text message instead.
Tightening later
Monitoring mode is the first step, not the destination. After a few weeks of clean reports, once every legitimate sender passes, a club can move the policy to p=quarantine and eventually p=reject. Large mailbox providers have been requiring authentication from bulk senders for some time, and a domain with an enforced policy is harder for criminals to impersonate. The club left it at none for a month, then moved to quarantine with a percentage, raising it gradually.
A ten-minute check
Send a message from your newsletter tool to a mailbox you control, open "show original" or "view headers", and look for the authentication results lines. Then query the records:
dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT sel1._domainkey.example.comIf a command returns nothing for a record you believe you published, check you added it at the right name: some control panels append the domain automatically, giving _dmarc.example.com.example.com. The DNS cheatsheet covers the common record forms, and the troubleshooting guide has a mail section.