DMARC Enforcement: Audit SPF, DKIM & Email Senders Before Reject

Before You Set DMARC to Reject: Audit Every Email Sender on Your Domain First

Picture this: you run a growing business on example.com. Every day, your domain handles a dozen different types of emails. Your team replies to clients through Google Workspace. Your WordPress site fires off contact form alerts and WooCommerce receipts via your hosting server. Your billing software sends out monthly PDF invoices, and your marketing team blasts newsletters through a third-party platform.

Everything works smoothly until you decide to tighten up your domain security. Reading up on email spoofing, you decide to lock things down with a strict DMARC policy and publish this DNS record:

v=DMARC1; p=reject; rua=mailto:[email protected]

By the afternoon, support tickets start trickling in. Customers aren't getting their password reset links. Invoices are vanishing into thin air. Your sales team hasn't received a single website lead all day.

What went wrong? You told the world's mail servers to reject unauthenticated mail from your domain before you actually mapped out every tool authorized to send mail on your behalf.

DMARC is essential for keeping spoofers and phishers off your domain, but flipping the switch to p=reject blindfolded will break legitimate business emails. The right way to deploy DMARC is to build a complete inventory of your email senders, configure SPF and DKIM properly, verify domain alignment, watch your aggregate reports, and only enforce a strict policy once the data proves you're ready.

In this guide, we will walk through that exact process step by step:

• Tracking down every service sending email from your domain
• Auditing your current SPF, DKIM, and DMARC records via command line
• Why SPF and DKIM can pass while DMARC still fails (the alignment trap)
• Setting up DMARC monitoring and reading aggregate reports
• Fixing common authentication failures on WordPress and third-party tools
• Safely moving from p=none to p=quarantine and p=reject
• Key changes in the 2026 DMARC standard (RFC 9989)

1. How SPF, DKIM, and DMARC Actually Work Together

Before touching your DNS zone, it helps to be clear on what each record actually authenticates—and where the gaps are.

What is SPF?

Sender Policy Framework (SPF) is a public list of servers and IP addresses allowed to send mail for your domain. When a server sends an email, receiving servers check the domain listed in the hidden SMTP envelope sender (also known as the Return-Path or bounce address) against your SPF TXT record:

v=spf1 include:mail-provider.example ~all

(Note: Always use the exact SPF string provided by your specific email host or transactional mail service.)

The catch with SPF is that it only checks the background envelope sender—not the visible From: address the recipient sees in their inbox. If a spoofer uses their own server and envelope domain, SPF passes for their domain while displaying your domain in the From: header.

What is DKIM?

DomainKeys Identified Mail (DKIM) stamps a cryptographic signature onto the email header. When the message arrives, the receiving mail server looks up your public key in your DNS records to verify that the signature belongs to your domain and that the message body wasn't altered in transit.

A DKIM header looks something like this:

DKIM-Signature: v=1; d=example.com; s=selector1;

Here, d= shows the signing domain, and s= points to the specific selector where the public key lives in DNS.

What is DMARC?

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is the glue that ties SPF and DKIM to the visible From: address. It checks whether the domain that passed SPF or DKIM actually matches (aligns with) the domain the recipient sees in their email client.

DMARC also tells receiving mail servers what you want them to do when an email fails that check, using one of three policy tags:

• p=none (Monitoring Mode): Take no action on failing emails, just send aggregate data reports to the domain owner so traffic can be audited safely.
• p=quarantine (Caution Mode): Treat failing emails as suspicious, usually routing them straight to the recipient's spam or junk folder.
• p=reject (Enforcement Mode): Block failing emails outright at the server level before they ever reach an inbox or spam folder.

Keep in mind that DMARC policies are formal requests, not ironclad laws; individual mail providers ultimately make their own filtering decisions based on local policies.

The Alignment Rule

For an email to pass DMARC, at least one authentication method (SPF or DKIM) must pass and align with your visible From: domain.

• SPF Check: Is the sending server authorized for the envelope Return-Path domain, and does that domain match the visible From: header?
• DKIM Check: Is the cryptographic signature valid, and does the d= signing domain match the visible From: header?

If an email passes SPF using a third-party provider's bounce domain, and isn't signed with your own custom DKIM key, SPF passes but DMARC fails. Configuring both SPF and DKIM alignment gives you a vital safety net—especially when emails get forwarded.

2. Audit Every Service Sending Email From Your Domain

This is where most migrations go sideways. Almost every business remembers to authenticate their primary workspace email, but forgets the half-dozen background scripts and SaaS tools quietly sending emails as @example.com.

Before editing a single DNS record, map out your entire email footprint:

• Google Workspace or Microsoft 365: Daily employee and team emails. Verify both SPF includes and custom DKIM keys.
• Web Hosting Mail Server: System alerts, cPanel/ioPanel notifications, and cron outputs. Verify server IP in SPF and local DKIM signing.
• WordPress & WooCommerce: Contact forms, password resets, and order receipts. Check your SMTP plugin configuration and From: address settings.
• Email Marketing Platforms (Mailchimp, Brevo, etc.): Newsletters and campaigns. Requires custom DKIM CNAMEs and custom bounce domains.
• CRM & Helpdesk Software (HubSpot, Zendesk, Freshdesk): Support tickets and sales follow-ups. Check custom sending domain verification settings.
• Billing & Invoicing Tools (Stripe, Razorpay, Zoho, WHMCS): Automated receipts and renewal notices. Verify custom SMTP or domain authentication keys.
• Server Monitoring & Uptime Tools: Alert emails sent from your domain. Verify sending identity and envelope alignment.

Step 1: Check Your Website's Mail Setup

If your site runs on WordPress or a custom PHP app, check how it dispatches outgoing mail. Is it using raw PHP mail() through the local web server, a hosting-provided SMTP account, or an external transactional API via an SMTP plugin? Check every form plugin, membership script, and e-commerce notification setting to see what From: address they use.

Step 2: Hunt Down Occasional Senders

Don't overlook tools that only send emails once a month or once a year—like automated quarterly billing scripts, off-site backup notifications, or domain/service renewal reminders. Because they fire rarely, they won't show up in a quick 48-hour DNS test.

Step 3: Keep a Simple Sender Log

Open a blank document or spreadsheet and log nine things for every service you find:

1. Service name
2. What kind of emails it sends
3. The visible From: address it uses
4. Current SPF requirement
5. DKIM selector (s=)
6. DKIM signing domain (d=)
7. Return-Path (bounce) domain
8. Date last tested
9. Current DMARC pass/fail status

3. Inspect Your Existing DNS Records

Once you have your list, pull up a terminal and check what your authoritative DNS servers (whether managed at your registrar, Cloudflare, or Hostomy) are currently broadcasting.

Step 1: Check Your SPF Record

Run the following command (replace example.com with your domain):

dig TXT example.com +short

Look for the string starting with v=spf1, such as:

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

Two critical rules for SPF:

1. One SPF record per hostname: Never create two separate v=spf1 TXT records on the same domain. Having multiple SPF records triggers a permanent error (permerror) and breaks authentication for everything. Merge all your providers into a single record.
2. The 10 DNS Lookup Limit: The SPF specification caps evaluation at 10 DNS-querying mechanisms (include, a, mx, ptr, exists, and redirect), including nested lookups inside third-party includes. Exceeding 10 lookups results in an automatic SPF permerror.

Step 2: Check Your DKIM Records

DKIM keys live under ._domainkey subdomains using a specific selector name provided by your mail host. To test a known selector (like selector1 or google), run:

dig TXT selector1._domainkey.example.com +short

Many modern SaaS platforms delegate DKIM via CNAME records so they can rotate keys automatically. To check a CNAME-based DKIM setup, run:

dig CNAME selector1._domainkey.example.com +short

Step 3: Check Your Current DMARC Record

Query the _dmarc subdomain:

dig TXT _dmarc.example.com +short

If a record exists, it might look like v=DMARC1; p=none; rua=mailto:[email protected]. If the output comes back empty, you don't have DMARC configured yet.

Step 4: Check Your MX Records

Run:

dig MX example.com +short

MX records strictly dictate where incoming mail gets delivered. Deploying DMARC won't require changing your MX records, though checking them helps confirm your primary mail architecture.

4. Test Real Outgoing Emails and Check Alignment

Looking at DNS zones only tells you half the story. To see what receiving mail servers actually see, trigger real test emails from every platform on your list (send an invoice, submit your contact form, fire a test newsletter) to an external Gmail account.

How to Inspect Headers in Gmail

1. Open the test email in Gmail.
2. Click the three dots in the top-right corner of the message pane.
3. Click Show original.
4. Look at the top summary and inspect the raw Authentication-Results: header generated by Google.

Don't just look for the word PASS—look at the domains attached to each pass:

• Visible From Header: What domain is shown after From: (e.g., [email protected])?
• SPF Result & Domain: Which envelope domain passed SPF?
• DKIM Result & Domain: Which signing domain (d=) passed DKIM?
• DMARC Result: Did at least one of those passing domains match example.com?

Here is a real-world example of what you might see when a third-party transactional service sends mail for you:

From: [email protected]
SPF: PASS with domain bounce.mail-provider.net
DKIM: PASS with domain example.com
DMARC: PASS

Notice what happened here: SPF passed, but failed alignment because the envelope domain was bounce.mail-provider.net instead of example.com. However, because DKIM passed using example.com, DMARC still passed!

Now imagine if you hadn't configured custom DKIM for that provider, and it signed the email with d=mail-provider.net instead. Both SPF and DKIM would show PASS in the raw headers, yet DMARC would fail because neither domain matches example.com. That misalignment is the #1 reason legitimate emails get blocked when admins switch DMARC to reject.

5. Turn On DMARC Monitoring Mode (p=none)

Once your core services are checked, it's time to start gathering real-world telemetry without putting a single email at risk.

First, create a dedicated mailbox (like [email protected]) or set up an account with a DMARC report analyzer that gives you a dedicated reporting address.

Step 1: Publish the Monitoring TXT Record

Log into your authoritative DNS panel and add a new TXT record with these exact details:

• Record Type: TXT
• Host / Name: _dmarc (or _dmarc.example.com depending on your DNS panel)
• Record Value: v=DMARC1; p=none; rua=mailto:[email protected]
• TTL: Default / Automatic (or 3600 seconds)

Make sure you only have one _dmarc TXT record published.

Step 2: Verify Propagation

Wait a few minutes and verify via terminal:

dig TXT _dmarc.example.com +short

Step 3: Collect Aggregate Reports

The rua= tag tells participating mail providers (like Google, Yahoo, Microsoft, and corporate gateways) to send daily aggregate reports to your specified address.

These reports arrive as compressed XML attachments detailing:

• The ISP or mail receiver sending the report
• Every source IP address sending mail claiming to be from your domain
• Message volume per IP
• SPF and DKIM pass/fail rates and alignment statuses
• What disposition policy was applied

Because reading raw XML files every morning gets tedious fast, most sysadmins route their rua= address to a DMARC parser tool or open-source dashboard that visualizes the XML data cleanly.

6. How to Read and Act on Your DMARC Reports

After a couple of weeks of collecting reports, you'll typically see four distinct patterns emerge across your mail streams:

Pattern 1: Primary Business Email (SPF Pass, DKIM Pass, DMARC Pass)

Your main Google Workspace or Microsoft 365 setup shows 1,200+ messages passing both SPF and DKIM with full alignment. Nothing to fix here—this stream is rock solid.

Pattern 2: Web Hosting Server (SPF Pass, DKIM Fail, DMARC Pass)

Say your web server sent 300 system notifications. SPF passed and aligned, so DMARC passed, but DKIM failed or wasn't present. While DMARC is technically passing right now, relying solely on SPF is risky. If a customer auto-forwards your email to another address, SPF will break in transit. Go into your hosting control panel and enable DKIM signing for your domain so both protocols protect those messages.

Pattern 3: Newsletter or CRM Platform (SPF Pass, DKIM Pass, DMARC Fail)

You see 800 marketing emails where both SPF and DKIM say Pass in raw auth, but DMARC says Fail. As we covered earlier, this is classic misalignment. The newsletter tool is authenticating with its own domain (mailchimp or sendgrid.net) instead of yours. You need to log into that platform's dashboard and configure custom domain authentication.

Pattern 4: Unknown IP Address (SPF Fail, DKIM Fail, DMARC Fail)

You spot 95 emails coming from an unfamiliar IP failing everything. Don't panic and assume you're under cyberattack right away. Perform a reverse DNS lookup (dig -x <IP>) or check the WHOIS data for that IP. Half the time, an "unknown IP" turns out to be an old staging server, a forgotten printer/scanner emailing PDFs, or an external billing plugin nobody documented. Only after ruling out your own tools should you classify it as unauthorized spoofing.

7. Fixing Common Alignment & WordPress Issues

Once your reports highlight which legitimate tools are failing DMARC, here is how to fix the three most common culprits.

Fix 1: SPF Passes, But Fails Alignment

If a third-party service sends mail from [email protected] using an envelope address like [email protected], SPF won't align. Look in your provider's domain settings for Custom Return-Path or Custom Bounce Domain. They will usually ask you to point a CNAME record (like bounce.example.com) to their server. Once active, the envelope sender lives under your domain, and SPF aligns automatically.

Fix 2: DKIM Passes, But Fails Alignment

If your alerts from [email protected] are signed with d=vendor.com, enable Custom DKIM Signing inside that vendor's settings. They will generate one to three TXT or CNAME records for you to paste into your DNS zone. Once verified, outgoing messages will carry d=example.com, satisfying DMARC alignment.

Fix 3: WordPress Contact Forms Spoofing Visitor Addresses

This is a classic trap for web developers and agency owners. Many poorly configured WordPress contact forms take whatever email address a visitor types into the form (say, [email protected]) and put it directly into the From: header:

From: [email protected]

When your server sends that email to you, your server is literally spoofing gmail.com. Because your hosting server isn't authorized by Google's SPF or DKIM records, Gmail and other strict receivers will reject or spam-folder the notification.

The proper configuration: Always set your contact form's From: address to an address on your own authenticated domain, and put the visitor's email in the Reply-To: header:

From: Website Contact Form <[email protected]>
Reply-To: [email protected]

Pair that with a dedicated SMTP plugin authenticating through your hosting mail server or transactional mail provider, and your form leads will hit your inbox every single time—while allowing you to click "Reply" to respond directly to the visitor.

8. Moving Safely From Monitoring to Enforcement

Once every legitimate sender on your inventory is passing DMARC with proper alignment, you can begin stepping up your policy.

Don't rush this based on an arbitrary 7-day timer. Your timeline depends entirely on your billing and communication cycle. If your company sends automated invoices on the 1st of every month, you must monitor for at least one full monthly cycle to verify those invoices pass authentication.

The Safe Rollout Sequence

1. Stage 1 (p=none): v=DMARC1; p=none; rua=mailto:[email protected] — Collect reports, map senders, and fix SPF/DKIM alignment.
2. Stage 2 (p=quarantine): v=DMARC1; p=quarantine; rua=mailto:[email protected] — Instruct receivers to send unauthenticated mail to spam. Watch your reports and check with customers/staff to ensure no legitimate mail was caught.
3. Stage 3 (p=reject): v=DMARC1; p=reject; rua=mailto:[email protected] — Instruct receivers to block unauthenticated mail completely.

A Crucial Warning on Mailing Lists and Forwarding

In the 2026 DMARC specification (RFC 9989), the IETF specifically cautions against blindly enforcing p=reject on general-purpose domains where employees participate in external internet mailing lists or heavy alumni/university email forwarding.

Why? Because mailing lists often append footers to emails or modify subject lines (adding [List-Name]), which breaks your cryptographic DKIM signature—while forwarding breaks SPF because the mailing list server's IP isn't in your SPF record.

If your team relies heavily on external discussion lists, RFC 9989 recommends staying at p=none for at least 30 days, testing p=quarantine for another 30 days, and ensuring every outgoing email carries a valid DKIM signature before ever considering p=reject.

9. Important Changes in the 2026 DMARC Standard (RFC 9989)

If you've read older DMARC guides from a few years ago, you need to know about major updates published by the IETF in May 2026 across three core documents:

• RFC 9989: The new core DMARC specification (which officially obsoletes RFC 7489 and RFC 9091).
• RFC 9990: Updated standards for DMARC aggregate reporting.
• RFC 9991: Updated standards for DMARC failure reporting.

Goodbye pct=, Hello t= (Testing Tag)

For years, tutorials told admins to roll out strict policies incrementally using the percentage tag, like v=DMARC1; p=reject; pct=20, to apply rejection to only 20% of failing messages.

RFC 9989 officially removes the old pct tag and replaces it with the new t (testing mode) tag:

v=DMARC1; p=quarantine; t=y; rua=mailto:[email protected]

Here is how the t tag works under the 2026 standard:

• t=n (Default): The published policy (quarantine or reject) is applied normally.
• t=y (Testing Mode): Signals to participating receivers that you are testing a stricter policy. Under t=y, a p=quarantine policy is stepped down and handled as p=none, while a p=reject policy is stepped down and handled as p=quarantine.

Keep in mind that t=y does not do percentage-based sampling, and because receiver adoption of new RFC tags takes time, you should still rely on a deliberate step-by-step progression from p=none to p=quarantine while watching your aggregate reports.

10. Current Gmail and Yahoo Bulk Sender Requirements

Even if you aren't ready for p=reject, configuring DMARC is no longer optional if you send mail at scale.

Gmail's Rules

Google classifies any domain sending roughly 5,000 or more emails within a 24-hour window to personal @gmail.com or @googlemail.com accounts as a bulk sender. Note that traffic across all your subdomains rolls up into your primary root domain's count—and once your domain crosses that 5,000-message threshold, the "bulk sender" status is permanent.

To reach Gmail inboxes, bulk senders must have:

• Valid SPF authentication
• Valid DKIM authentication
• A published DMARC record (at least p=none) with passing alignment on either SPF or DKIM (Google strongly recommends aligning both)
• Valid forward and reverse DNS (PTR records) on sending IPs, plus one-click list-unsubscribe headers on marketing mail

Yahoo's Rules

Yahoo enforces nearly identical requirements for bulk senders—requiring SPF, DKIM, and a minimum DMARC policy of p=none with proper alignment—though Yahoo does not publish a fixed daily message count for its bulk threshold.

Remember: passing SPF, DKIM, and DMARC gets you through the front door, but inbox placement still depends on low spam complaint rates, clean lists, and solid IP reputation.

11. Quick Troubleshooting Guide & Security Notes

If something breaks during your audit or rollout, check these common failure points:

• DMARC record isn't detected by lookup tools: Check your DNS host field. Many DNS managers automatically append .example.com to the Name field—if you typed _dmarc.example.com, you may have accidentally created _dmarc.example.com.example.com.
• SPF permerror in headers: You either published two separate v=spf1 TXT records on the same host, or your include: statements exceed the 10-lookup limit. Consolidate into a single record and remove unused third-party includes.
• SPF or DKIM passes, but DMARC fails: You have an alignment mismatch. Configure a custom Return-Path bounce domain for SPF, or set up custom domain DKIM keys (d=example.com) with your third-party sender.
• No aggregate reports are arriving in your inbox: Verify that your rua=mailto: syntax includes the mailto: prefix, that the destination mailbox actually exists, and that you aren't sending reports to an external domain without publishing an external reporting authorization record.
• Legitimate emails started going to spam after switching to p=quarantine: Drop your DNS record back to p=none immediately, wait for TTL propagation, and inspect the headers of the quarantined messages to see which sender you missed.

A Note on Report Security

DMARC aggregate reports contain sensitive operational metadata about your infrastructure, including internal IP addresses and mail volumes. If you build an internal script or self-hosted parser to ingest rua XML archives, follow RFC security guidelines: restrict dashboard access, enforce strict zip/gzip extraction size limits to prevent zip-bomb resource exhaustion, and disable external entity processing (XXE) in your XML parser.

Frequently Asked Questions

Does setting up DMARC automatically boost my email deliverability?

DMARC proves your identity and blocks phishers from ruining your domain's reputation, which protects your deliverability over the long haul. And if you're a bulk sender, having DMARC is mandatory to avoid throttling at Gmail and Yahoo. However, DMARC alone won't save poorly written spammy emails from going to the junk folder.

Should I jump straight to p=reject when creating my first DMARC record?

Never. Even if you think you only use Google Workspace, jumping straight to p=reject almost always breaks forgotten website notifications, billing receipts, or CRM integrations. Always start at p=none and verify with aggregate reports first.

How can SPF pass while DMARC fails?

SPF checks the hidden Return-Path envelope address, while DMARC checks the visible From: address. If a marketing platform sends an email using its own bounce domain (bounce.marketing-app.com), SPF passes for that domain—but because it doesn't match your visible @example.com address, DMARC alignment fails.

Do I need to create a separate DMARC record for every subdomain?

No. A DMARC record published on your root domain (_dmarc.example.com) automatically covers all subdomains unless a subdomain has its own specific _dmarc record. You can also use the sp= tag in your main DMARC record to set a different default policy specifically for your subdomains.

Will adding a DMARC record break my incoming emails?

No. Incoming mail routing is controlled by your MX records. Your _dmarc TXT record only instructs other mail servers on how to verify outgoing emails that claim to come from your domain.

Can I configure SPF, DKIM, and DMARC on shared hosting?

Absolutely. Because SPF, DKIM, and DMARC live entirely inside your domain's DNS zone as standard TXT and CNAME records, you can configure them across shared hosting, NVMe VPS instances, dedicated servers, and external email suites alike.

Wrapping Up: Audit First, Enforce Later

Locking down your domain with DMARC isn't a five-minute task of pasting p=reject into your DNS panel—it's an visibility exercise. The hardest part isn't writing the TXT syntax; it's uncovering every script, plugin, and third-party tool sending mail on your business's behalf.

Take the methodical route: inventory your senders, inspect your existing DNS records, send real test emails to verify header alignment, turn on p=none reporting, fix the stragglers, and step up your policy only when your reports are clean.

Running Your Website and Email on Hostomy?

Whether your site sends WooCommerce order receipts, contact form alerts, or automated client invoices, reliable delivery starts with clean server IPs, proper local DKIM signing, and rock-solid DNS configuration.

If you host your websites or applications on Hostomy and want to make sure your hosting-side mail, SPF includes, and DKIM keys are properly aligned before tightening your DMARC policy, reach out to our support team anytime—we're happy to help you audit your setup. Looking for fast, dependable infrastructure with full DNS control? Explore Hostomy's NVMe SSD shared and cloud VPS hosting plans today.