Before you start: a quick refresher
DMARC is a rule that tells email inboxes (like Gmail or Outlook) what to do with email that claims to come from your company but can't prove it. Think of it like a bouncer checking IDs at the door. If an email can't prove it's really from you, DMARC tells the inbox to either let it through anyway, hold it for review (quarantine), or block it completely (reject).
For DMARC to "prove" an email is legitimate, the email needs to pass one of two checks:
SPF – checks whether the email came from a server your company approved.
DKIM – checks whether the email has a digital signature that proves it wasn't changed in transit.
If an email passes either SPF or DKIM, and the domain used in those checks matches the domain the recipient sees in the "From" field, the email passes DMARC. If neither check lines up, the email fails DMARC.
Valimail Enforce gives you three tools to figure out what's going on when something isn't authenticating correctly:
Authentication Report – shows you who is sending email as your domain, and whether it's passing or failing.
Domains Report – shows you the big picture across all your domains, so you can spot problems at a glance.
Alerts – notify you automatically the moment something changes, so you don't have to go looking for trouble.
The rest of this article walks through the recommended workflow for using these tools to troubleshoot a problem, along with some important context on rejections and other reasons mail can be blocked that have nothing to do with DMARC.
The recommended troubleshooting workflow
When you get a report that email isn't authenticating, isn't being delivered, or is being flagged as suspicious, work through these steps in order. Each step narrows things down until you find the actual cause.
Step 1: Start broad with the Domains Report
Before you dig into one specific sender, get the big picture first.
Open the Domains Report and find the domain that's having trouble.
Look at the DMARC Pass Rate, SPF Pass Rate, and DKIM Pass Rate columns. A drop in any of these tells you where to focus.
Check the Suspicious Emails column. A high number here can mean spoofing, but it can also mean a legitimate sender that just isn't set up correctly yet.
Look at the Allowed Through, Quarantined, and Rejected columns to understand what's actually happening to the mail right now under your current policy.
Use the Date Received filter to check whether the problem is new or has been ongoing. This helps you figure out if something recently changed.
This step tells you which domain has a problem and roughly how bad it is. Next, you need to find out who is causing it.
Step 2: Narrow down with the Authentication Report
Once you know which domain is affected, drill into the specific sending service or vendor causing the failure.
Open the Authentication Report for that domain.
Look through the list of known services and find the one you suspect is having trouble (for example, a marketing platform, a vendor, or an internal system).
Group your attention by category:
Mostly Passing (95%+): healthy, no action needed.
Partially Passing (50–95%): something is inconsistent. This often means only some of the sender's servers are properly configured.
Mostly Failing (below 50%): this sender is very likely not authenticated at all yet.
Unidentified Senders: traffic Enforce can't match to any known service. This could be a new system nobody registered yet, or it could be spoofed mail.
Click into the specific service to see its SPF and DKIM pass rate (left side below the chart). If the sender isn't included in your SPF configuration, or DKIM isn't set up, expect to see lower pass rates.
If your plan includes the Source IPs tab, check whether the sender is using an IP address you don't recognize. Vendors sometimes change sending infrastructure without notice, which breaks SPF alignment.
Step 3: Confirm the timeline
Use the date picker in either report (up to 6 months of history) to pinpoint exactly when the pass rate changed. A sudden drop that lines up with a specific day usually points to a specific event, a vendor changing servers, a DKIM key rotating, a new campaign tool being turned on, or a policy change on your end.
Step 4: Review email headers and bounceback messages for rejected mail
When actual rejections are reported by end users (someone says a specific email never arrived), the reports in Enforce show you the pattern across many messages, but they won't show you every detail of that one specific email. For that, it helps to also look at:
The email header of the message in question (if you can get a copy of it, or ask the sender/recipient to forward the raw message). The header will show you the actual SPF and DKIM results the receiving mail server recorded, the sending IP address, and the path the message took. This confirms whether the message failed authentication, and if so, exactly why.
The bounceback (non-delivery report/NDR) the sender received. Bouncebacks usually include a status code and a short explanation from the receiving mail server about why the message was rejected. This is often the fastest way to tell whether a rejection was actually caused by DMARC, or by something else entirely (see below).
Reviewing the header and bounceback alongside the Enforce reports gives you both sides of the picture: the big-picture pattern from Enforce, and the specific detail from the one message that was reported as a problem.
Step 5: Fix the root cause
Depending on what you found, this usually means one of the following:
Adding a sender's IP range to your SPF configuration in Enforce.
Getting an updated DKIM key from a vendor and adding it in Enforce.
Asking a vendor why they changed their sending setup without notice.
Step 6: Set up an Alert so you catch it sooner next time
Most of the issues you'll troubleshoot have a matching Alert you can configure so you hear about it automatically instead of waiting for a complaint:
Enabled Senders DMARC Alert – notifies you when an approved sender's pass rate drops.
New Services Detected Alert – notifies you when a new sender starts sending mail as your domain.
Suspicious Sending Alert – notifies you when unidentified traffic crosses a threshold you set (only available for domains not yet at full enforcement).
DKIM Key Manager Alert (Enforce Enterprise) – notifies you when a DKIM key is added, removed, or getting old.
DMARC Policy Alert (Enforce Enterprise) – notifies you whenever your DMARC policy changes.
Record Configuration Change Alert (Enforce Enterprise) – notifies you when your DMARC, SPF, or other DNS records change, which helps catch typos or accidental changes quickly.
Important: not every blocked or rejected email is a DMARC problem
It's easy to assume that any bounced or missing email is a DMARC failure, especially once you've set up enforcement. In reality, DMARC is only one of many reasons a receiving mail server might block, quarantine, or reject a message. Some other common causes include:
Spam and content filtering: the receiving server's spam filter flagged something in the subject line, body content, links, or attachments, regardless of whether the message authenticated correctly.
Sender reputation or blocklists: the sending IP address or domain has a poor sending reputation (often from past spam complaints or a history of sending to invalid addresses), or it's listed on a public blocklist. This can cause rejections even with perfect SPF and DKIM.
Rate limiting or throttling: sending too many messages too quickly can cause a receiving server to temporarily reject or delay mail, independent of authentication.
Invalid or full recipient mailbox: the address doesn't exist, is misspelled, or the mailbox is full. This shows up as a bounce but has nothing to do with your domain's authentication.
Greylisting: some receiving servers temporarily reject the first attempt from an unfamiliar sending server on purpose, expecting a legitimate sender to try again a few minutes later. This looks like a rejection but usually resolves itself.
Malformed message structure: formatting errors in the email itself (broken headers, oversized attachments, invalid character encoding) can cause a receiving server to reject the message before authentication is even checked.
This is exactly why reviewing the bounceback message (Step 4 above) matters so much. The status code and explanation in the bounceback will usually tell you plainly whether the rejection was DMARC-related or caused by one of these other factors. If the bounceback doesn't mention authentication, SPF, DKIM, or DMARC at all, the Enforce reports likely aren't going to explain the failure; you'll need to look at whatever system flagged the message (spam filter, reputation service, or the receiving mail server itself).
When to contact Valimail Support
Reach out to the Support team if:
You see unidentified traffic that you believe is legitimate (for example, a newly added internal system). Support can add it to the list of known services so it stops showing as unidentified.
You've reviewed the bounceback and header and confirmed the rejection was DMARC-related, but you can't find the cause in the Enforce reports.
Related articles: