How to Fix DMARC Rejections When Your SEG or Proofpoint Configuration Changes

What the rejection looks like

A user reports that email to a specific domain started bouncing. The bounce message cites DMARC failure. The sending domain has not changed its DNS records. SPF and DKIM for the domain look correct when you check them manually. But the recipient server is rejecting the message with something like "550 5.7.1 DMARC policy violation."

This is not a content filter problem. The message is not being held for review. It is being rejected outright because the recipient server ran a DMARC check and the message failed alignment.

If a SEG or Proofpoint configuration changed recently in your environment, that is the first thing to investigate.

Why SEGs break DMARC alignment

DMARC requires that at least one of SPF or DKIM passes alignment. Alignment means the domain used in the authentication check must match the RFC 5321 From domain. A message can have a valid SPF record and valid DKIM signature for its own domain, but still fail DMARC if a third party is relaying or processing the message on behalf of the sender.

When a SEG or Proofpoint appliance processes outbound email, it often does one of two things:

Direct MX mode. Incoming mail from the internet hits the SEG first. The SEG scans it, then relays it to the internal mail server. Outbound mail from the internal server goes directly to the internet. This mode does not usually affect DMARC alignment for outbound mail.

Integrated routing or relay mode. The SEG acts as the actual sending MTA. Outbound mail originates from the SEG's own IP addresses and infrastructure, not from the customer domain's mail servers. The SEG signs some or all outbound messages with its own DKIM keys or sends from its own SPF-aligned IPs.

In integrated routing mode, the SEG's infrastructure is the sending identity. The SEG's From domain may not match the customer domain. When the recipient server evaluates the DMARC record for the customer domain, neither SPF nor DKIM will align with that domain's From address. The result is a DMARC rejection of legitimate email.

The issue is not that the SEG is broken. It is that the SEG is sending as the wrong identity.

Proofpoint is a common example. Proofpoint's On Demand and On Premise products can operate in a mode where the Proofpoint server is the visible sending MTA for outbound mail. If DMARC is set to reject or quarantine on the customer domain, the first time this mode activates, the domain starts failing DMARC at recipient servers that enforce it.

How to diagnose which authentication mechanism is failing

You need to know whether SPF, DKIM, or both are failing alignment. DMARC reports are the primary diagnostic tool.

Step 1. Find your DMARC record and note the rua address. If your DMARC record does not include a rua directive, add one before doing anything else. Without aggregate reports, you are working without visibility.

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; pct=100

Replace example.com with your actual domain. Point the rua address at a mailbox you check, or route it to a DMARC monitoring service.

Step 2. Read the DMARC reports. Look for your domain in the aggregate reports from participating recipient servers. The report will show pass or fail for DKIM and SPF separately, along with the aligned domain used.

The key fields are and results inside each . You want to see whether these are "pass" or "fail," and whether the aligned domain matches your From domain.

If you cannot wait for reports, a quick manual check: send a test message to a Gmail address and look at the message headers in the received copy. Gmail publishes authentication results in the Authentication-Results header. Look for dmarc=pass or dmarc=fail.

Step 3. Identify the vendor's sending domain. In DMARC reports, look for the HELO/EHLO name or the sending IP in the field. If the sending IP belongs to your SEG vendor's range, that is confirmation the SEG is the origin.

Proofpoint typically sends from IPs in the Proofpoint netblock. If you see Proofpoint IPs in your DMARC reports as the source of messages with your From domain, the SEG is generating the alignment failure.

How to fix the issue with your SEG vendor

The fix depends on the SEG's configuration and the vendor's willingness to support aligned authentication.

Fix 1. Request aligned DKIM signing from the vendor.

The cleanest fix is for the SEG to sign outbound messages with a DKIM key where the selector domain matches your From domain. This requires the SEG to use your domain's DKIM private key or a key the SEG generates on your behalf that uses your domain as the signing domain.

Not all SEG vendors support this. Some charge extra for it. Some only sign with their own domain, which does not help with DMARC alignment.

Ask your vendor specifically: "Does your platform support DKIM signing using our own sending domain rather than yours?" If the answer is yes, you need to configure the SEG to use your domain's DKIM selector. You will need to add or verify the DKIM TXT record for that selector in your own DNS.

Fix 2. Configure SPF to include the SEG vendor's IPs.

If the SEG must send from its own IP range, you can add those IPs to your SPF record. This requires the SEG vendor to publish their sending IP ranges accurately and notify you when they change. It also requires your SPF record to stay within the 10-DNS-lookup SPF limit, which is easy to hit if you have many third-party senders.

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com
include:spf.proofpoint.com ~all

Replace spf.proofpoint.com with whatever vendor prefix your SEG uses. Add this to your existing SPF record, not as a replacement.

Fix 3. Bypass the SEG for aligned sending.

Some organizations resolve this by configuring their internal mail system to send directly to the internet for specific domains or message types, bypassing the SEG for outbound relay. The SEG still processes inbound mail. This restores DMARC alignment because the internal MTA sends from the correct IP range.

This is not always possible depending on your SEG's licensing model or your internal routing constraints.

Fix 4. Temporarily lower the DMARC policy while you resolve it.

If email is being rejected and you need time to negotiate a fix with the SEG vendor, change your DMARC policy from reject to quarantine as a temporary measure:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; pct=50

Lower pct to a small percentage first. Watch your DMARC reports. Once the SEG fix is confirmed working, restore p=reject and pct=100.

Do not leave this as a permanent state. Quarantine policy means rejected email is delivered to spam instead of being rejected outright, which is better for production mail flow but still means recipient servers are not enforcing your DMARC policy.

How to catch the next SEG configuration drift before it causes an outage

SEG configuration changes are one of the most common causes of sudden DMARC failures in environments that use third-party email security vendors. The SEG's behavior can change without notice when the vendor pushes an update, changes a default routing setting, or migrates your tenant to new infrastructure.

The only reliable way to catch this before users report it is ongoing DMARC report monitoring.

DMARC aggregate reports arrive daily from participating mailbox providers. Each report tells you how many messages from your domain arrived at each receiving server, and whether they passed or failed SPF and DKIM. When your SEG starts sending misaligned mail, you will see a sudden spike in DKIM failures or SPF failures in the reports, depending on which mechanism is affected.

Ongoing monitoring is what makes the difference here. You can review DMARC reports manually, but that is time-consuming and easy to skip when the inbox is busy. Tools like DMARCFlow can monitor your aggregate reports and alert when alignment failures spike, so the first you hear about a SEG configuration change is an alert, not a call from a user whose email bounced.

The monitoring habit that matters most: whenever your SEG vendor notifies you of a configuration change, a platform update, or a tenant migration, check your DMARC reports within 24 hours. Do not wait for the next scheduled review.

Summary checklist

• Check DMARC reports to confirm the sending IP belongs to your SEG vendor, not your own MTA
• Identify which authentication mechanism is failing: SPF alignment, DKIM alignment, or both
• Request aligned DKIM signing from your SEG vendor, or add the vendor's IPs to your SPF record
• If you need time to negotiate a fix, lower p=reject to p=quarantine temporarily
• Set up ongoing DMARC monitoring with alerts for sudden spikes in authentication failures
• After any SEG configuration change or vendor update, review DMARC reports within 24 hours