Audit Your Domain Email Security: SPF, DKIM, DMARC, and SSL Step by Step

For your emails to reach the inbox and prevent anyone from spoofing your domain, you need three DNS records — SPF, DKIM, and DMARC — properly configured, plus a valid SSL certificate. That is the entire foundation of domain security, and the good news is that you can audit it yourself in about 15 minutes without installing anything.

And in 2026 this is no longer optional. Since 2024, Google and Yahoo reject or send to spam email from senders who don’t authenticate their domain, and the rule has been tightened across the board. If your quotes, invoices, or password-reset emails are landing in spam — or worse, if someone is sending phishing in your company’s name — the cause is almost always the same: the domain is not authenticated.

In this guide I’ll explain, without unnecessary jargon, what each protocol does, what a real configuration looks like, and how to audit your domain step by step with free tools.

Why Your Emails Go to Spam: Domain Health Matters

When you send an email, the receiving server (Gmail, Outlook, etc.) asks itself one question before deciding where to put it: “Can I trust that this message really comes from who it claims to come from?” To answer that, it checks your domain authentication.

If your domain does not have that authentication configured, one of two things happens:

• Your legitimate emails land in spam or get rejected outright.
• Anyone can forge your address (spoofing) and send phishing to your clients in your name.

The three protocols that solve this work in layers, each building on the one before:

Protocol	What it answers	Record type	Where it lives
SPF	Which servers can send on my behalf?	TXT	yourdomain.com
DKIM	Did the message arrive intact and signed by me?	TXT	selector._domainkey.yourdomain.com
DMARC	What happens if SPF or DKIM fail?	TXT	_dmarc.yourdomain.com

If you want to review how DNS records work before diving in, I have a dedicated guide on DNS record types and how they propagate.

SPF: Authorize Who Sends on Your Behalf

SPF (Sender Policy Framework) is a public list of the servers authorized to send email using your domain. It is a single TXT record at your domain’s root.

Here is what a typical SPF record looks like for a domain that sends through Google Workspace:

v=spf1 include:_spf.google.com ~all

Breaking it down:

• v=spf1 — protocol version (always this).
• include:_spf.google.com — authorizes Google’s servers. Add every provider that sends on your behalf here: your CRM, invoicing platform, Mailgun, etc.
• ~all — softfail: all other servers are flagged as suspicious but not rejected. Once everything is working, upgrade to -all (hardfail) for maximum protection.

🔧 To see the real SPF of any domain without installing anything, look up its TXT record with my free DNS Lookup tool. If two v=spf1 records appear, you’ve found your first problem (see below).

The golden rule of SPF: one record only and a maximum of 10 DNS lookups. Chain too many include directives and SPF stops validating.

DKIM: The Signature That Proves Authenticity

If SPF says who can send, DKIM (DomainKeys Identified Mail) proves that the message was not altered in transit and that it genuinely came from you. It works with public-key cryptography:

1. Your server signs each outgoing email with a private key.
2. You publish the public key in a TXT record under a selector.
3. The receiving server retrieves that public key and verifies the signature.

The record lives at selector._domainkey.yourdomain.com and looks something like this:

google._domainkey.yourdomain.com  TXT
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."

Where google is the selector (defined by your provider) and p= is the public key. You do not need to generate it by hand: your email provider gives you the exact value to paste into DNS. Your only job is to publish it and confirm it resolves.

DMARC: The Policy That Ties Everything Together (and Sends You Reports)

SPF and DKIM on their own don’t tell the recipient what to do when something fails. That is the job of DMARC (Domain-based Message Authentication, Reporting & Conformance): the policy that ties the two previous layers together and, on top of that, sends you reports about who is using your domain.

The record lives at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:[email protected]; adkim=s; aspf=s; pct=100

• p= — the policy: what to do with email that fails authentication.
• rua=mailto: — where to send aggregate reports (review them: they tell you who is sending in your name).
• adkim=s / aspf=s — strict alignment between the signing domain and the visible one.

The key is rolling out the policy in stages — never start by blocking:

Stage	Policy	What it does	When to advance
1. Monitor	p=none	Blocks nothing, only reports	After 1–2 weeks of clean reports
2. Quarantine	p=quarantine	Sends suspicious mail to spam	When nearly everything passes authentication
3. Reject	p=reject	Blocks impersonation	This is the final goal

Always start at p=none, read the reports, fix any providers that were not authenticated, and only then tighten the policy. Jumping straight to p=reject is the fastest way to block your own legitimate email.

Verify Your SSL and DNS Configuration

Domain security doesn’t end with email. The SSL/TLS certificate is what encrypts your website traffic (the browser padlock) and is also a trust signal for Google. An expired certificate takes down your site and drives away any potential client.

What to check in your SSL:

• That it is valid and current (not expired).
• That it covers the correct domain, including www if you use it.
• That the certificate chain is complete (a missing intermediate breaks the padlock on some devices only).

🔒 Verify the validity, issuer, and chain of your certificate with my SSL Lookup tool. It tells you how many days remain before expiry — set a reminder before that date.

And if you need to check the IP address serving your domain or its geolocation — useful for detecting where your email or hosting actually points — use the IP Lookup.

Complete Audit in 15 Minutes

🚀 Prefer the shortcut? My Email Auth Checker reviews SPF, DKIM, and DMARC in one shot and gives you a grade from A to F with recommendations. And if you want a walkthrough of the 7 free tools for auditing your domain, read this practical guide.

This is the exact checklist I follow when auditing a domain. Run it with DNS Lookup and SSL Lookup open in another tab:

• SPF exists and is unique. Look up the root TXT: there must be only one v=spf1 record.
• SPF does not exceed 10 DNS lookups. Too many include directives invalidate it.
• DKIM resolves. Query selector._domainkey.yourdomain.com and confirm it returns the public key.
• DMARC exists. Check _dmarc.yourdomain.com and that rua= points to a mailbox you actually monitor.
• DMARC policy is appropriate for your maturity level (none to start, reject as the goal).
• SSL is valid and the chain is complete.
• No upcoming expiry: note the certificate’s expiration date.

If all seven points are green, your domain is authenticated and protected. If any fail, you know exactly what to ask your provider or developer for.

Common Mistakes That Break Deliverability

These are the ones I see again and again:

• Two SPF records. There can only be one; if you added a new provider without merging, SPF stops validating. Combine them into a single line with multiple include directives.
• Switching email providers and forgetting SPF/DKIM. You migrate to a new service and emails start landing in spam because DNS still authorizes the old provider.
• DMARC at p=reject from day one. You block your own legitimate email (newsletters, invoices, site notifications) before authenticating them.
• rua= pointing to a mailbox nobody reads. DMARC reports are gold for detecting impersonation; if you’re not reviewing them, you’re flying blind.
• Expired SSL. Without a reminder, the certificate expires on a Sunday and by Monday your site shows as “not secure.”

Conclusion

Authenticating your domain is not a technical luxury: it is what separates your emails arriving from ending up in spam, and what prevents someone from impersonating your brand. SPF says who sends, DKIM signs that the message is yours, DMARC decides what happens when something fails, and SSL encrypts and builds trust. With the right tools, auditing all of this takes minutes.

If you run the audit and something doesn’t add up — or you’d rather have someone lock down your domain, email, and site all at once — I can help. Take a look at my web development service or, if your goal is to get your operation’s infrastructure in order, custom systems.

Frequently Asked Questions

What is the difference between SPF, DKIM, and DMARC? SPF says which servers can send on your behalf, DKIM signs the message to prove it is yours and was not altered, and DMARC decides what to do when something fails (and sends you reports). They work in layers.

Why do my emails go to spam? Almost always because the domain is not authenticated. Since 2024, Google and Yahoo require SPF + DKIM + DMARC; without them, your legitimate email goes to spam or gets rejected.

How do I verify for free? By checking the TXT records in your DNS (root for SPF, selector._domainkey for DKIM, and _dmarc for DMARC) with a DNS Lookup tool.

Have you checked whether your domain is authenticated? Let me know what your audit turned up.