Is your custom domain email being delivered? Why SPF, DKIM, and DMARC matter now
Summary:
SPF, DKIM, and DMARC are three small DNS records that prove your email is genuinely from you
Google, Yahoo, and Microsoft have all tightened enforcement over the past two years, and missing or misconfigured records now cause emails to land in spam or get rejected outright
This post is for custom domain owners (you@yourbusiness.com); if you only use a public email service like @gmail.com or @icloud.com, you can skip this one
Any unused domains you own should also be locked down so spammers can't impersonate you, which takes only a few minutes per domain
A client emailed me a few weeks ago, frustrated. Her outgoing email kept ending up in recipients' spam folders, and she'd noticed a pattern: it was almost entirely happening when the recipient had a Gmail address. Mail to people on other services usually got through fine. She'd been living with it, but a large mailing was coming up and she needed it fixed beforehand.
The cause was something most people have never heard of: SPF, DKIM, and DMARC. When her email was set up, these weren't enforced. They are now.
Who is this for?
If you have a custom domain (your email address ends in something like @yourbusiness.com instead of @gmail.com), this post is for you. If you only use a public email service like Gmail, iCloud, Yahoo, or AOL, you can skip it. The big providers handle all of this on your behalf.
The short version
SPF, DKIM, and DMARC are three small records you publish in your domain's DNS settings. When they're set up correctly, your email gets delivered and other people can't easily impersonate you. When they're missing or misconfigured, your email increasingly gets rejected or sent to spam, and your domain becomes an easier target for spoofing. The table below covers what each one does at a glance. If you'd rather have someone look at your setup for you, you can book a session with me or talk to your web developer.
SPF, DKIM, and DMARC at a glance
Three small DNS records that work together to prove your email is genuinely from you.
| SPF | DKIM | DMARC | |
|---|---|---|---|
| Full name | Sender Policy Framework | DomainKeys Identified Mail | Domain-based Message Authentication, Reporting, and Conformance |
| What it does | Publishes the list of mail servers allowed to send email for your domain. | Cryptographically signs each message so receivers can verify it came from your domain and wasn't tampered with. | Tells receiving servers what to do when SPF or DKIM fails, and optionally sends you reports on attempts to send as your domain. |
| Quick analogy | The list of approved senders at the front door. | A wax seal on the letter. | The rule book that ties it all together. |
| Without it | Anyone in the world can claim to send email from your domain. | Messages can be modified in transit or impersonated more convincingly. | Receivers are left guessing what to do when checks fail, so enforcement is inconsistent. |
You want all three. SPF and DKIM cover different attack patterns, and DMARC ties them together with enforcement and reporting.
What happens if you don't fix this?
Two things, both bad.
First, your own outgoing email starts landing in spam folders or getting rejected outright. In October 2023, Google and Yahoo jointly announced new requirements, with enforcement starting February 2024. Microsoft followed in May 2025. Then in November 2025, Gmail moved from temporary delivery deferrals to permanent rejections for non-compliant mail. If your domain was set up before 2023 and nobody has touched the DNS settings since, there's a real chance you're not fully compliant. The symptoms look like the story above: mail to Gmail recipients failing while mail to other providers mostly gets through.
Second, your domain becomes easier for scammers to impersonate. Recently another client came to me convinced his email had been hacked. He was receiving messages that appeared to be coming from his own email address, complete with his name in the From field. He hadn't been hacked. Someone was forging emails to look like they came from him, and without a strict DMARC policy on his domain, even his own mail server had no clear instructions to reject the messages on arrival. A DMARC policy of p=reject tells every receiving server, including his own, that anything failing the checks should be thrown out before it lands in anyone's inbox.
What about domains I'm not using?
If you own a domain you're not actively using to send email, it's still a target. Attackers specifically look for inactive domains because they know these are unmonitored and aren't properly authenticated. A phishing email claiming to come from your unused domain can still land in someone's inbox, even though you never sent it.
The good news: locking down an unused domain takes only a few minutes in your domain registrar's DNS settings. You publish two TXT records:
SPF record
Type: TXT
Host: @
Value: v=spf1 -all
DMARC record
Type: TXT
Host: _dmarc
Value: v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s;
Together, these tell every receiving mail server that no email should ever come from this domain or any of its subdomains, and anything claiming to should be rejected.
Every unused domain you own should be locked down this way. The cleaner and easier to navigate your registrar is, the less painful this is to do across multiple domains. That's part of why I recommend Namecheap for most people.
How do I check?
A free tool like MXToolbox lets you enter your domain and see what records are published. For an ongoing view, Postmark offers a free DMARC monitoring service that collects the daily reports receiving mail servers send back about messages claiming to be from your domain. It can be useful for discovering other legitimate sources of mail you may have forgotten about.
That said, reading these records and knowing whether they're configured correctly for your specific email provider is where things get technical. A record can exist but still be wrong. If you're a current client of mine and I have access to your domain registrar and email provider on file, you may be receiving a written report from me in the coming weeks showing what's set up correctly and what needs attention.
Key Takeaways
If you use a custom domain for email, check your SPF, DKIM, and DMARC records this month, or have someone check them for you.
Lock down any unused domains you own using the SPF and DMARC records spelled out above.
If any of this is over your head, that's normal. DNS and email authentication are genuinely technical even when the underlying ideas are not.
If you have a custom domain and aren't sure where you stand, I help clients with this during one-on-one tech tutoring in San Francisco and Washington DC, or remotely over Zoom. It can also be folded into a broader personal digital security audit covering passwords, two-factor authentication, and scam recognition. Your web developer is another good option if you already work with one. If you'd like to get on the schedule with me, you can book a session here.
