EAGLE SOLUTIONS
A domain checker put a yellow flag next to my own domain: “DMARC: Policy set to p=none – messages are logged but not blocked.” One sentence, and it is not obvious at first whether it deserves your attention.
It does. In plain words it means this: if somebody emails my clients using my address, the receiving server notices that it is forged – and delivers it anyway.
The fix is a single line in DNS. That is exactly what makes it dangerous: change only that line and there is a good chance you will silence your own contact form. That is very nearly what happened to me.
Three records, three sentences
Email authentication rests on three DNS records, and each answers a different question:
- SPF – which servers are allowed to send email on behalf of your domain.
- DKIM – a digital signature on the message itself, showing it was not altered in transit and really came from you.
- DMARC – what should happen when the first two do not line up, and who gets reports about it.
DMARC has three settings: `p=none` (log it, but deliver), `p=quarantine` (send it to spam) and `p=reject` (do not accept it at all). On most domains I look at, it is `p=none` – or nothing at all.
This is not a theoretical risk. A forged email from your address to your client – a quote, an invoice, a “our bank account has changed” notice – looks exactly like yours. Your client takes the loss, but your name stays on it.
The trap: your own website is a “foreign sender” too
Before changing anything, I checked what actually sends email in my name. It turned out that my own WordPress was the weakest link.
By default WordPress uses the server's plain mail function, and the sender is some `wordpress@yourdomain.com` address. That email lies to nobody, it simply matches neither SPF nor DKIM. Under `p=none` this can go unnoticed for years, because the consequence is exactly what `none` promises: none.
Switch from that state to `p=reject`, however, and from then on:
- the contact form notification never reaches you,
- the automatic confirmation to the visitor never arrives,
- the password reset email vanishes,
- and all of it happens silently: no error, no spam folder, it simply does not show up.
This is the most common mistake in this area. Turning DMARC on takes two minutes technically. Finding out what sends under your name – that is the actual work.
Measure it, do not guess
I use two free tools for this. Both show the same three things (SPF, DKIM, DMARC), just at different levels of detail:
- mail-tester.com – you get a single-use address, send a message to it, and get a score out of ten. Fast, but there is a daily quota.
- learndmarc.com – the same check, walked through step by step, and it shows alignment as well. No quota.
The detail most people get wrong: send the test from where your email actually originates. If you send from your mail client, you are testing whether your mailbox is fine – and it probably is. Your website sends along a completely different path. In my case, that was exactly where the difference was.
What to look for: SPF and DKIM should not merely “pass”, they must also align with the domain of the visible sender. DMARC is not decided by whether some signature exists on the message, but by whether that signature belongs to your domain.
The fix: let the website send from a real mailbox too
The solution is not magic: stop letting WordPress use the server's anonymous mailer, and have it send over authenticated SMTP from a real mailbox of yours – in my case the `hello@` address. That way the sender belongs to the domain that SPF and DKIM already cover.
One thing needs care, though, or you end up worse off than before. Until now the sender on your contact form notification was the visitor's address – which is why you could simply hit “Reply”. If you rewrite the sender to your own address and do nothing else, “Reply” goes back to yourself.
The correct approach: the sender is your mailbox (that is what makes it authenticated), and the visitor's address moves into the Reply-To header. Everything is proper on the outside, and replying works for you exactly as it did before.
What I got wrong – and what only a header check revealed
I wrote the code, sent the test message, and the result was 10/10: SPF, DKIM and DMARC all green. I could have stopped there.
I did not stop, because I looked at more than the score – I looked at the message headers, and Reply-To was missing. It was a bug in my own code: I was rewriting the sender at a point that runs before the visitor's address can be saved. By the time I wanted to set Reply-To, the original address no longer existed.
The score would have stayed perfect. In practice, though, every single enquiry would have required copying the email address by hand out of the message body. After a week that is annoying; after a month it is a source of mistakes.
That is the driest but most important sentence in this article: an overall score is not a verification. Look at the actual headers too – sender, Return-Path, Reply-To – because authentication can be flawless while the email is still wrong for daily use.
The result
The same path, before and after the fix:
- Before: sender `wordpress@…`, SPF not aligned, no DKIM, DMARC `p=none` – meaning anyone could write in my name and the receiving server delivered it regardless.
- After: the sender is my real mailbox, SPF ✓ and aligned, DKIM ✓ (2048-bit signature) and aligned, DMARC ✓ even under the strictest `p=reject` policy – and the visitor's address sits in Reply-To, so replying is unchanged.
I pointed the DMARC reports at a free service that sends a readable weekly summary of who tried to send in my domain's name. Human sentences instead of raw XML, one email a week.
What to watch afterwards
Once DMARC is enforced, the rule stays in force: every new service that sends using your address must first be added to SPF and set up with DKIM. Invoicing software, newsletter tools, CRM, booking systems, helpdesks – any of them. Otherwise their messages disappear silently.
This is not an argument against tightening. It simply means that sending email is part of the system just like the domain or the hosting – it does not work by itself, it needs maintenance.
Who should care
Anyone with their own domain and a contact form. It is specifically urgent if:
- you send invoices or quotes by email,
- your clients might receive financial instructions from you,
- you run an online store that sends order confirmations,
- or it simply matters that your email does not land in the spam folder.
The check takes five minutes and costs nothing: send a test message from your website to one of the tools above and look at those three lines. If any of them is red, there is work to do.
If you would rather not get into it, take a look at the monthly care plans – checking and maintaining email authentication is part of them. If you just have one specific question, drop me a line.
The same way of thinking runs through the piece where I ran three SEO audits on my own site: there too, the point was that a warning and reality are not the same thing – you have to measure.
