If you ship transactional email from a SaaS product, AI agent, or background worker, three DNS records decide whether your message lands in the inbox or gets bounced before a human sees it. The target: a green pass on SPF, DKIM, and DMARC at every major mailbox provider, with an aligned envelope-from domain. Most teams trip on the path there.
SPF, DKIM, and DMARC are the three DNS records every app sending email must configure. Failing any of them causes deferrals or rejections on Gmail and Outlook under the 2024 bulk-sender enforcement that remains in effect in 2026. DMARC alignment requires both an SPF pass with a matching envelope-from domain and a DKIM signature with a matching d= tag. A misaligned DMARC record can still report aligned in some tools while failing at the inbox, which is why teams think they are configured correctly until support tickets land.
Bavimail generates and verifies all four records (SPF, DKIM, DMARC, and MAIL FROM) programmatically via the /domains/{id}/setup and /domains/{id}/verify endpoints, with no manual DNS pasting required. Below: what each record does, why alignment matters most, and how to confirm your sending domain survives the 2026 inbox.
What do SPF, DKIM, and DMARC actually do?
SPF (Sender Policy Framework) is a DNS TXT record that lists the IP addresses and sending services authorized to send mail on behalf of your domain. When a receiver gets a message claiming to be from you, it checks the envelope-from address against your SPF record. If the sending IP is not on the list, SPF fails.
DKIM (DomainKeys Identified Mail) is a cryptographic signature on the message itself. The sender publishes a public key in DNS, signs each outbound email with the matching private key, and the receiver verifies the signature. DKIM survives forwarding in a way SPF does not, because the signature travels with the message rather than relying on the network path.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the policy layer. It tells receivers what to do when SPF or DKIM fail, and it requires that at least one of the two passes with a domain that aligns with the visible From header. Without DMARC, SPF and DKIM are advisory. DMARC at p=reject protects your domain from spoofing and gives your legitimate mail a trust signal at every major provider.
MAIL FROM (sometimes called Return-Path or bounce address) is the envelope-level sender. By default many email APIs use their own bounce domain, which causes SPF to authenticate against the provider rather than your domain. Configuring a custom MAIL FROM subdomain is what makes SPF alignment work for DMARC.
Why does DMARC alignment fail when SPF and DKIM "pass"?
This is the most common trap in dmarc transactional email setup. A debugger like mail-tester or MXToolbox shows SPF pass and DKIM pass, and yet your DMARC report still shows fail. The cause is almost always alignment.
Alignment means the domain that authenticated must match the domain in the visible From header. SPF alignment requires the envelope-from domain (the MAIL FROM) to match the header From. DKIM alignment requires the d= tag in the DKIM signature to match the header From. If you send from hello@yourapp.com but your envelope-from is bounces@some-esp.net and your DKIM d= is some-esp.net, both protocols passed for the provider's domain, but neither aligned with yours. DMARC fails.
The fix is to send through a provider that signs DKIM with your domain (custom DKIM keys, not shared) and uses a MAIL FROM subdomain on your domain (like bounces.yourapp.com). Without both, you cannot reach a clean DMARC pass.
What changed with Gmail and Yahoo bulk-sender enforcement?
In February 2024, Gmail and Yahoo rolled out enforcement that turned best-practice email authentication 2026 senders inherit into a hard requirement. Senders pushing more than 5,000 messages per day to Gmail or Yahoo accounts must have all of the following:
- A valid SPF record covering every sending IP
- A valid DKIM signature aligned with the From domain
- A DMARC record at minimum p=none, published on the From domain
- One-click unsubscribe via the List-Unsubscribe-Post header
- A spam rate below 0.3 percent reported in Google Postmaster Tools
The 5,000 threshold is public, but in practice enforcement bites at far smaller volumes. A new sending domain with no DMARC and a mismatched MAIL FROM will see deferrals at single-digit volumes. The 2024 rules remain the baseline in 2026, and Microsoft followed with similar enforcement on outlook.com and hotmail.com inboxes.
For transactional email, the implication is that your password resets, magic links, and order confirmations face the same authentication bar as a marketing newsletter, even though they are one-to-one messages. A user who never gets a password reset email never logs in, never converts, and often blames your product rather than their inbox provider.
How do you set up MAIL FROM correctly for transactional email?
MAIL FROM is the record most teams skip, because most spf dkim dmarc setup walkthroughs treat those three records as the full list. MAIL FROM is the fourth, and skipping it is what breaks SPF alignment.
A custom MAIL FROM is a subdomain (typically bounces.yourapp.com or mail.yourapp.com) with two records:
- An MX record pointing to your provider's bounce-handling host
- A TXT record with an SPF policy authorizing your provider
Once you publish those records, your provider rewrites the envelope-from to use that subdomain, which gives you SPF alignment with the visible From header. Without it, your SPF check passes but points at the wrong domain, and DMARC fails alignment.
For a deeper walkthrough of how all four records get scoped on a sending subdomain, the domain verification docs cover the exact DNS shape including SPF includes, DKIM selector format, and DMARC policy progression from p=none to p=reject.
How can you verify all four records programmatically?
Manual DNS pasting is where setup goes wrong. Typos, missing TXT records, wrong selector names, and DMARC policies that do nothing are the rule rather than the exception. Programmatic domain verification removes the human error.
With Bavimail, you POST to /domains with your sending domain, then call /domains/{id}/setup to get the exact records you need to publish, then call /domains/{id}/verify to confirm propagation and validate the DNS state. The verify endpoint resolves your authoritative nameservers, checks each record, validates DKIM key length and SPF includes, and confirms DMARC is published on the right host with a policy you can act on.
The domain verification feature handles all four records in one flow: SPF (including the Bavimail include), DKIM (a 2048-bit key on a unique selector), DMARC (a configurable policy with reporting addresses), and MAIL FROM (a scoped bounces subdomain with the MX and SPF records published together). The /verify endpoint returns a per-record status, so you can build domain setup into your own onboarding without making users round-trip through a DNS console you cannot see.
What does a passing transactional sender look like in 2026?
A correctly configured 2026 transactional domain has SPF pointing at the precise services you send through, DKIM signed with a domain-aligned key, DMARC at p=reject (or at minimum p=quarantine after a monitoring period at p=none), and a MAIL FROM subdomain that gives SPF something to align against. It has Google Postmaster Tools and Microsoft SNDS connected. It has List-Unsubscribe and List-Unsubscribe-Post headers on every message. An automated check verifies it, not a screenshot from a DNS console six months ago.
Get the records right once, automate the verification, and your transactional email stops breaking when a deploy moves a sending IP or a provider rotates a key. Start with Bavimail's domain verification flow to publish, verify, and monitor SPF, DKIM, DMARC, and MAIL FROM programmatically, and ship the rest of your product instead of debugging DNS records.