Blog · Dmarc
Why Proofpoint Rejects Email Citing DMARC (And How to Fix It)
Proofpoint is rejecting your email and the bounce message says DMARC. Your SPF record is correct. Your DKIM record is correct. Your DMARC record looks fine. So what is going on?
The problem is almost always the same: you are confusing DMARC passing with DMARC alignment. They are not the same thing. Proofpoint checks both.
The distinction matters because DMARC aggregate reports are the only way to see which specific alignment check is failing. Without reading those reports, you are guessing. Here is what that distinction actually means in practice, and how to find the real cause using your DMARC reports.
What DMARC Alignment Actually Means
DMARC has two separate requirements that must both be satisfied:
1. At least one authentication mechanism (SPF or DKIM) must pass
2. The domain that passed authentication must align with the domain in your visible From header
You can pass SPF and DKIM and still fail DMARC if the domains do not align. This is the most common reason Proofpoint rejects legitimate email.
DMARC alignment works like this:
- SPF alignment: the domain in the envelope MAIL FROM (also called the return-path) must match the domain in the From header
- DKIM alignment: the domain in the DKIM signature's
d=tag must match the domain in the From header
If either one aligns, DMARC passes. If neither aligns, DMARC fails, and Proofpoint enforces its policy at that point.
How Proofpoint Evaluates DMARC
Proofpoint applies DMARC checks as part of its email filtering pipeline. It does this in two layers.
Layer one is standard DMARC evaluation. Proofpoint looks at the sending domain's published DMARC policy and applies it. If your policy is p=reject, Proofpoint rejects messages that fail alignment. If it is p=quarantine, it marks them as suspicious.
Layer two is Proofpoint's own reputation system, which runs alongside DMARC. A domain can pass DMARC alignment checks but still get rejected if Proofpoint's filters flag the sender as suspicious for other reasons. When Proofpoint cites DMARC specifically, it usually means the alignment check failed, not that Proofpoint's reputation system is the primary cause.
The SMTP rejection code for a DMARC failure typically looks like this:
550 5.7.1 DMARC policy violation
If your logs show this, your DMARC alignment is failing. Here is how to find out why.
The Four Most Common Causes of Proofpoint DMARC Rejections
1. DKIM Signature Is Not Aligned
Your email is signed with DKIM using a selector that belongs to a third-party sending service, not your own domain. The signature passes DKIM verification, but the d= domain in the signature does not match your From header domain.
For example: you use SendGrid to send marketing email. SendGrid signs the email with its own DKIM key. The signature passes DKIM checks. But the DKIM d= domain is sendgrid.net, not yourdomain.com. When Proofpoint checks alignment, it compares the From header (yourdomain.com) against the DKIM d= domain (sendgrid.net). They do not match. Alignment fails.
This is the single most common cause of DMARC rejections from third-party email senders, and it is almost never obvious from looking at your DNS records alone.
2. SPF Passes but Envelope Sender Differs From From Header
The envelope MAIL FROM domain (the return-path) does not match your From header domain. SPF verifies the envelope sender, not the From header. If the domains differ, SPF can pass while DMARC alignment still fails.
This is common with bulk email providers that use their own bounce domain. The envelope sender is bounces.sendgrid.net while the From header shows yourdomain.com. SPF passes because the IP is authorized for sendgrid.net. But DMARC alignment fails because the domains do not match.
3. Email Forwarding Broke the Authentication Chain
If your email was forwarded, the forwarder became the new sender for SPF purposes. The original SPF check no longer applies to the forwarder's IP. The forwarded message also typically loses its original DKIM signature. If the forwarder does not implement Sender Rewriting Scheme (SRS) correctly, SPF fails entirely, and DKIM is gone.
If your DMARC policy is p=reject, forwarded messages that broke the chain will be rejected at the final destination. This is a structural problem with plain email forwarding. It is not spoofing. The email is legitimate but the forwarding infrastructure does not preserve authentication.
4. Subdomain Sending Without Subdomain DMARC Policy
You are sending from subdomain.yourdomain.com but your DMARC record is published on yourdomain.com. The organizational domain of subdomain.yourdomain.com is yourdomain.com. If your DMARC policy is on the apex only and you have not explicitly set a policy for the subdomain, DMARC evaluation uses the apex policy on the subdomain's From header. This can cause misalignment if your sending infrastructure does not align with the subdomain.
In practice: if your SPF record says include:_spf.sendgrid.net and your DKIM is set up for sendgrid.net, but you are sending from marketing.yourdomain.com, the DKIM d= will be sendgrid.net not marketing.yourdomain.com. Alignment fails.
How to Diagnose the Specific Cause
You need your DMARC aggregate reports. Here is how to find and read them.
Step 1: Locate your DMARC record's reporting address
Your DMARC DNS record contains a tag like rua=mailto:reports@yourdomain.com that specifies where aggregate reports are sent. If you do not have this configured, your reports are not being collected anywhere. Set this up first.
Step 2: Read the reports with a DMARC monitoring tool
Raw DMARC reports arrive as XML attachments. Parsing them by hand is slow and error-prone. A DMARC monitoring tool like DMARCFlow reads every report and shows you the alignment results in plain English, so you can identify which sending service is failing alignment without manually scanning XML.
If you receive raw XML reports by email, the relevant sections for a DKIM alignment failure look roughly like this:
sendgrid.net
pass
default
sendgrid.net
pass
yourdomain.com
fail
fail
The section tells you exactly which authentication method failed and why. If you see DKIM fail, your DKIM signature domain does not match your From header domain. If you see SPF fail, your envelope sender domain does not match.
Step 3: Identify the pattern
Run this analysis across all the reports you receive. If every failure shows the same third-party domain (e.g., sendgrid.net) in both the DKIM d= and the envelope MAIL FROM, you know exactly which sending service is causing the misalignment.
How to Fix Each Cause
Fixing DKIM Alignment Failures
Audit every sending service that sends email on behalf of your domain. For each service, check whether it provides DKIM keys tied to your domain (which gives aligned DKIM) or uses its own domain (which does not).
If you have multiple email senders, you need DKIM keys for your domain at each one. Many sending services have documentation for setting up custom DKIM domains. Use it.
Remove or migrate any old email senders you no longer use. Old selectors in your infrastructure may still be signing email with a domain you no longer control.
After making changes, wait for your next DMARC report cycle (usually 24-48 hours) and verify that aligned DKIM is now passing.
Fixing SPF Alignment Failures
The fix for SPF alignment failures is to audit your envelope MAIL FROM configuration. Some email services use their own bounce domain by default. You need to set a custom return-path domain that uses your own domain, or configure the sending service to use your domain as the MAIL FROM.
If you use a third-party bulk sender and cannot change their MAIL FROM domain, you have two options:
- Accept that alignment will fail and keep your DMARC policy at
p=noneto avoid rejections - Route that sending stream through your own mail server, which can set the correct envelope domain
Fixing Forwarding Problems
You cannot fix forwarding problems for email you do not control. If the forwarding service does not implement SRS correctly, forwarded mail from your domain will fail DMARC at the receiver.
If you are the forwarder, implement SRS. If you are the sender, document the forwarding path in your DMARC reports and consider using p=quarantine instead of p=reject if forwarding is common for your recipients.
Some mailing lists and forwarding services now implement ARC (Authenticated Received Chain), which preserves the original authentication results through the forwarding chain. If your recipients' email services support ARC, forwarded mail may be treated more leniently.
Fixing Subdomain Sending Issues
Set explicit DMARC policies for subdomains you use for sending. The cleanest approach is to publish a separate _dmarc.subsubdomain.yourdomain.com record with its own policy, or use a wildcard *._dmarc.yourdomain.com to cover all subdomains at once.
If the subdomain is used by a third-party sender, the same DKIM alignment rules apply. You need aligned DKIM from your own domain, not the sender's domain.
Getting Removed From Proofpoint's Rejection List
If your domain is actively being rejected by Proofpoint-protected recipients, you need to request delisting directly from Proofpoint. This is separate from fixing your DMARC configuration.
Visit Proofpoint's delisting portal and provide:
- Your sending domain
- The IP addresses you send from
- Confirmation of the DMARC fix you made
Proofpoint typically responds within one to two business days. Fix your DMARC alignment first, then submit the delist request with evidence of the fix. If you submit a delist request without fixing the underlying problem, your domain will be rejected again.
Preventing Future Proofpoint DMARC Rejections
Set up ongoing DMARC monitoring. DMARC reports are sent to you precisely so you can spot alignment failures before they become rejection complaints.
Review your aggregate reports at least monthly. Look for any new sending sources you did not expect, any new DKIM selectors that are failing alignment, and any sudden changes in failure rates.
When you change email sending providers, audit the new provider's DKIM setup before you start sending. Set up aligned DKIM before you send the first message.
If you manage multiple sending services, maintain a current inventory of every service that sends email on behalf of your domain. An unexpected sending source often signals a forgotten integration or an offboarded vendor whose credentials were not revoked.
Use a DMARC monitoring tool that flags failures in plain English instead of requiring you to parse raw XML. The faster you know about an alignment failure, the faster you fix it before Proofpoint or any other gateway starts rejecting your mail.
FAQ
Why does DMARC fail even when SPF and DKIM both pass?
DMARC requires alignment, not just passing authentication. If your SPF or DKIM passes but the authenticated domain does not match your From header domain, DMARC alignment fails. This is the most common cause of DMARC rejections for legitimate email.
Why does Proofpoint specifically reject my email citing DMARC?
Proofpoint enforces your DMARC policy. If your policy is p=reject and either SPF or DKIM fails alignment, Proofpoint rejects the message. The rejection code 550 5.7.1 specifically indicates a DMARC policy violation.
Can forwarding break DMARC alignment?
Yes. When an email is forwarded, the forwarder becomes the responsible party for SPF. If the forwarder does not implement Sender Rewriting Scheme (SRS), SPF fails. DKIM is also typically lost. If your DMARC policy is p=reject, forwarded messages that lose authentication alignment will be rejected.
Where do I find my DMARC aggregate reports?
Look for the rua tag in your DMARC DNS record. It specifies the email address or endpoint where reports are sent. If you are not receiving reports, your rua tag may not be configured or your DMARC record may be missing it entirely.
How do I fix DKIM alignment failures with third-party email senders?
Set up custom DKIM keys with the third-party sender using your domain, not theirs. Most major email sending services provide documentation for this. You need the DKIM d= domain to match your From header domain exactly.