Application Email Rejected or Junked After a Server Move: SPF, DKIM, DMARC and PTR

Direct answer: after a migration, an application usually sends mail from a new public IP address, or through a different relay, than before. Receiving systems check four things against that new path:

• whether the domain's SPF record authorises the new address;
• whether the message carries a valid DKIM signature;
• whether the domain in the visible From address aligns with the SPF or DKIM domain for DMARC;
• whether the sending IP has matching forward and reverse DNS (PTR).

If the old server signed mail, or sent through a relay the SPF record already covered, and the new one does neither, mail starts failing.

Send a test message to a mailbox you control, read its Authentication-Results header, and fix exactly what failed there. Plan the DNS changes with whoever owns the domain. If the application relays through Microsoft 365, also check that the relay connector or SMTP sign-in still matches the new server.

Why it matters

Password resets, invoices, alerts and order confirmations stop arriving, often without the application logging an error, because the relay accepted the message and the rejection or junking happened later at the recipient.

Large mailbox providers have raised their requirements:

• Gmail's published sender guidelines require all senders, from 1 February 2024, to set up SPF or DKIM, have valid forward and reverse DNS for sending domains or IPs, and use TLS. Senders of more than 5,000 messages a day to Gmail must also have SPF and DKIM, DMARC (policy may be none), and From alignment with the SPF or DKIM domain.
• Microsoft's Outlook.com post of 2 April 2025, updated 29 April 2025, applies to consumer domains (outlook.com, hotmail.com, live.com). For domains sending more than 5,000 messages a day, it requires SPF, DKIM and DMARC. It states that non-compliant messages are rejected with 550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level, taking effect from 5 May 2025.

Check both pages for changes before you rely on them. Their requirements and dates are the providers' and change over time.

The scheduled-jobs article under Related articles covers duplicate work after a migration. This article covers outbound mail authentication after the move.

How it works

SPF

SPF lets a domain list the hosts allowed to send with that domain in the SMTP envelope sender (MAIL FROM), or in the HELO name. The receiver evaluates the domain's TXT record against the connecting IP address.

RFC 7208 limits the evaluation:

• The include, a, mx, ptr and exists mechanisms, and the redirect modifier, all cause DNS queries. Implementations MUST limit the number of these terms evaluated during one check to 10, and return permerror if the limit is exceeded. Terms are evaluated left to right and evaluation stops at the first match, so a sender matched by an early ip4: term can pass while a sender matched late, or not at all, hits the limit. Nested include and redirect targets count towards the same total.
• "Void lookups", which return no answer, SHOULD be limited to two.

Adding one more include: for a new relay can push some evaluation paths past the limit. Any sender whose check has to evaluate more than 10 such terms gets permerror. A sender matched by an earlier term may still pass, so the effect depends on where each legitimate sender matches.

DKIM

DKIM adds a signature header. The signing domain (d=) and selector (s=) point to a public key published at <selector>._domainkey.<domain>.

If the old server signed mail with a private key that did not move with it, or the new relay signs with a different domain, the DKIM result changes.

DMARC alignment

DMARC, published at _dmarc.<domain>, ties the result to the From header domain the user sees. It passes when SPF or DKIM passes and that authenticated domain aligns with the From domain.

In relaxed mode, the default for both adkim and aspf, the organisational domains must match. In strict mode, the full names must match.

A common migration failure is an application that sends with From: alerts@example.com through a third-party relay whose envelope sender and DKIM domain belong to the relay. Both SPF and DKIM pass, but neither aligns, so DMARC fails.

Reverse DNS

The sending IP's PTR record should name a host whose A or AAAA record points back to the same IP, so that forward and reverse lookups agree. After a migration, the new public IP often has a generic provider PTR, or none. The PTR record is set by whoever controls the IP address block, usually the hosting provider, not in your own domain's DNS zone.

Microsoft 365 application sending

Microsoft documents several ways for a device or application to send through Microsoft 365:

• Client SMTP submission to smtp.office365.com on port 587 with a mailbox sign-in. Microsoft notes that this method with Basic authentication is scheduled for deprecation.
• SMTP relay to the tenant's MX endpoint on port 25, authenticated by an inbound connector, for example by static IP address.
• Direct Send, which is unauthenticated and cannot relay to the internet (recipients in your own domains only).
• High Volume Email, for internal recipients.

If the connector trusts the old server's public IP, relaying from the new IP fails or is treated as unauthenticated.

Read-only checks

None of these was run for this article. They need access to a test mailbox, the application's mail settings, and read access to DNS. The DNS and header reads are passive. The test message in step 1 is a real send through the production path, so use a mailbox you control and expected content.

1. Send a test message from the application to a mailbox you control at a large provider and to an internal mailbox. Record the time and the application's SMTP settings, but never copy relay passwords into tickets.

2. Read the received headers. Find the Authentication-Results header added by the receiving system (RFC 8601 format). For example:

Authentication-Results: mx.receiver.example;
  spf=fail smtp.mailfrom=bounces.example.com;
  dkim=none;
  dmarc=fail header.from=example.com

Also find the IP address the receiving system accepted the message from over the internet. Do not assume it is in the topmost Received header: that entry can describe a later internal hop inside the receiver. Use the Received entry added by the receiver's external inbound server, the one whose host matches the authserv-id at the start of Authentication-Results (here mx.receiver.example), or a connecting-IP field the receiver documents, such as client-ip= in some Received-SPF headers. That is the address SPF and PTR are evaluated against.

3. Read the DNS records involved.

nslookup -type=TXT example.com
nslookup -type=TXT _dmarc.example.com
nslookup -type=TXT <selector>._domainkey.example.com
nslookup -type=PTR <sending-ip>
nslookup <name-returned-by-PTR>

Count the DNS-querying terms in the SPF record, including those inside every include:, and compare the total with the limit of 10. This full count is a conservative screen: a total of 10 or less means no path can exceed the limit. A higher total does not by itself mean every message fails; work out the terms evaluated for each legitimate sending path, as in the decision guidance below.

4. Compare old and new paths. Did the old server send directly, through a smart host, or through Microsoft 365? Which public IP did it use? Did it sign with DKIM? The relay or MTA logs on both systems show this.

5. Microsoft 365 relay. In the Exchange admin centre, read the inbound connector used for relaying, and check whether it is limited to specific sender IP addresses. If the application uses client submission, confirm which mailbox it signs in with.

Interpreting the results

Decision guidance

Each DNS change is made by the domain owner. Write down the current record value before every change, so that rollback means republishing the saved value.

Authorise the new path in SPF

Add exactly the new source: an ip4: or ip6: term for a dedicated server address, or the relay provider's documented include:. Remove the old server's term once the old path is retired.

• Verification: a new test message shows spf=pass, and every legitimate sending path stays at or below 10 DNS-querying terms. Counting every term across all nested includes is a conservative screen: if that total is 10 or less, no path can exceed the limit.
• Rollback: republish the saved record.

Sign with DKIM under the From domain

Configure signing on the new MTA or relay with a new selector, publish the public key at <selector>._domainkey.<domain>, and confirm the signature uses d= in the From domain or its organisational domain. Keep the old selector record until mail signed with the old key is no longer in transit.

• Verification: dkim=pass with the expected header.d, and dmarc=pass.
• Rollback: disable signing on the new path, and leave the published key in place until mail signed with it is no longer in transit.

Reverse DNS

Ask the hosting provider to set the PTR for the sending IP to a host name whose A record returns the same IP. If the application sends through a relay, the relay's IP is what matters, not the application server's.

• Verification: forward and reverse lookups agree.

Microsoft 365 relay

Update the connector to the new static public IP. Or, where it suits the volume and recipients, move to one of the methods Microsoft recommends instead of client submission with Basic authentication.

• Verification: a test message to an external recipient arrives, with SPF covering the tenant's sending path as Microsoft documents for that method.
• Rollback: restore the connector's previous IP list.

DMARC policy

Do not tighten the DMARC policy as part of a migration fix. If no record exists and the domain owner wants one, starting with p=none and aggregate reporting gives visibility without affecting delivery.

What not to do

• Do not add +all or a very broad IP range to SPF to make mail pass. That authorises anyone to send as the domain.
• Do not add include after include without counting lookups. A sender whose evaluation exceeds the limit gets permerror, and adding a term near the front of the record can push later senders over it.
• Do not change the From address to a free mailbox domain to get around DMARC.
• Do not paste relay passwords or DKIM private keys into tickets or chat.
• Do not delete the old DKIM selector or SPF terms until the old path is confirmed unused.

Limitations

• Provider requirements and enforcement dates are the providers' published statements at the access date, and can change.
• Microsoft 365 options, limits and deprecation timelines are documented by Microsoft and change. Read the current page before you choose a method.
• Many receivers apply reputation and content filtering beyond authentication. Passing SPF, DKIM and DMARC does not guarantee inbox placement.
• PTR changes depend on the IP owner's process.

Acceptance checklist

• [ ] Test message headers saved, with SPF, DKIM and DMARC results and the connecting IP
• [ ] Old and new sending paths documented (direct or relay, public IP, signing)
• [ ] SPF lookup count checked for every legitimate sending path (or the full expansion total at or below 10), with the new source authorised
• [ ] DKIM signing in place with aligned d=, and selector record published
• [ ] PTR for the sending IP resolves forward to the same IP
• [ ] Microsoft 365 connector or submission settings match the new server, if used
• [ ] Previous DNS record values saved for rollback
• [ ] Repeat test meets the recipients' requirements for this path: at least spf=pass or dkim=pass with dmarc=pass for low-volume senders; both spf=pass and dkim=pass, plus dmarc=pass, where a recipient requires it (for example more than 5,000 messages a day to Gmail or Outlook.com consumer domains)
• [ ] DMARC alignment confirmed under the domain's actual policy (relaxed or strict aspf/adkim)
• [ ] Delivery verified at an external mailbox, not only internally, accepting that passing authentication does not guarantee inbox placement

References

All accessed 2 November 2026.

• RFC 7208, Sender Policy Framework (4.6.4 DNS Lookup Limits): https://www.rfc-editor.org/rfc/rfc7208.txt
• RFC 6376, DomainKeys Identified Mail (DKIM) Signatures: https://www.rfc-editor.org/rfc/rfc6376.txt
• RFC 7489, DMARC (3.1 Identifier Alignment, 6.1 policy record, adkim and aspf defaults): https://www.rfc-editor.org/rfc/rfc7489.txt
• RFC 8601, Message Header Field for Indicating Message Authentication Status: https://www.rfc-editor.org/rfc/rfc8601.txt
• Google Workspace Admin Help, Email sender guidelines (requirements for all senders and for more than 5,000 a day): https://support.google.com/a/answer/81126?hl=en
• Microsoft Defender for Office 365 Blog, Outlook's New Requirements for High-Volume Senders (2 April 2025, updated 29 April 2025): https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730
• Microsoft Learn, How to set up a multifunction device or application to send email using Microsoft 365 or Office 365: https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365
• Microsoft Learn, Set up SPF to identify valid email sources for your Microsoft 365 domain: https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure

Related articles

• Scheduled Jobs After Migration: Prevent Duplicate Work
• DNS Changed but Users Still Reach the Old Application
• Server Up, Application Unusable: Build Better Health Checks

Learning notes

1. After a move, the sending IP and relay path change. SPF, DKIM, DMARC and PTR are evaluated against the new path.
2. The Authentication-Results header of a test message is the evidence. Fix what it says failed.
3. SPF is limited to 10 DNS-querying terms per evaluation, including nested includes. A sender whose evaluation path exceeds it gets permerror; one matched by an earlier term may still pass, so check every sending path.
4. DMARC needs SPF or DKIM to pass with a domain aligned to the visible From domain.
5. PTR is set by the IP owner, and Microsoft 365 relay connectors often trust a specific public IP that changed in the move.