Why does SPF pass but alignment fail when display names have accents?

You send a message with a display name like “José” or “München” — clean, correct, and perfectly valid. The SPF check passes. The server says everything’s fine. But DMARC alignment still fails. Why?

The issue isn’t with SPF. It’s with how email clients and servers parse display names when they contain accented characters. That innocent “é” or “ü” can trigger unexpected MIME encoding, break header parsing, and ultimately cause DMARC alignment to drop — even when the sender’s address is technically valid.

SPF only checks the MAIL FROM address in the SMTP envelope. It doesn’t look at the display name at all. So a passing SPF check doesn’t guarantee alignment. The real problem surfaces later, during DMARC evaluation — where the display name, encoded incorrectly, disrupts the comparison between the From: header and the MAIL FROM domain.

Key takeaways

  • Accented characters in display names can cause MIME encoding anomalies that break DMARC alignment, even with SPF pass.
  • SPF validation doesn’t examine the display name — only the MAIL FROM address — so a pass does not imply alignment.
  • Many email systems expect display names to be ASCII-only; non-ASCII characters can trigger parsing errors during DMARC evaluation.

How display names affect DMARC alignment

You might pass SPF but still fail DMARC alignment if your From: header contains accented characters in the display name. This happens because UTF-8 encoding can alter how the domain part is parsed, breaking the alignment check between the MAIL FROM domain and the From: domain—even when SPF validates cleanly. Email providers like Gmail and Outlook treat this misalignment as a potential spoofing signal, increasing the chance your message lands in spam.

Why display names matter in DMARC

DMARC alignment requires that the domain in the MAIL FROM (used by SPF) matches the domain in the From: header (from RFC 5322). If your sender name includes accented characters—like Émilie, José, or Münch—email clients often encode the display name using UTF-8. This encoding can shift the position of the domain part in the header string, creating subtle parsing differences.

For example, a From: header like "Émilie <[email protected]>" might get parsed into a different structure than expected, especially if the client or mail server doesn't handle the UTF-8 transition correctly. The SPF check passes because it sees the domain in MAIL FROM, but DMARC fails due to mismatched domains in the alignment check.

How this impacts deliverability

Even if SPF passes, a DMARC alignment failure can signal to providers like Google or Microsoft that the email might be impersonating a brand. This reduces inbox placement and can hurt long-term sender reputation. It’s not just about technical perfection—it’s about consistency in how domains are validated across protocols.

Many organizations overlook this because they assume a valid From: address is enough. But when accented names are part of the sender display, the parsing differences can be enough to trigger a failure. Testing your email headers under real-world conditions is the only way to verify alignment remains intact.

If you're sending campaigns with international names or multilingual content, use tools like MailTester’s email checker to preview how your headers appear after encoding, and ensure your From: line stays aligned with your MAIL FROM domain. This helps prevent subtle alignment issues before they affect delivery.

For deeper insight, refer to the standards defining header structure and encoding: RFC 5322 and RFC 6376, which detail how From: headers and alignment are validated across the email ecosystem.

What does 'SPF pass but alignment fails' mean in practice?

When your email passes SPF but fails alignment, it means your sending server is authorized (SPF pass), but the domain in the From: header doesn't match the domain used for SPF authentication. This misalignment often triggers spam filters, even if the IP is trusted. The result? Your message lands in spam, gets rejected, or is marked as risky—especially when using display names with accented characters that break header parsing.

Why alignment matters more than SPF alone

SPF only confirms the IP address is allowed to send for a domain—but it doesn’t verify who’s sending on behalf of whom. That’s where DKIM and DMARC come in. DMARC checks alignment between the From: domain and the domains used in SPF and DKIM. If they don’t match, even a passing SPF check isn’t enough.

For example, if you send from example.com using an IP authorized for mailer.example.com, and your From: header is something like María López <[email protected]>, the mailer domain and from domain don’t align. This mismatch is a red flag to DMARC policies.

How accented characters disrupt alignment

Accented characters in display names—like É, ñ, or ç—can cause encoding issues if headers aren’t properly set. The From: line might be parsed incorrectly, leading the receiving server to misidentify the From: domain. This is a documented issue in RFC 5322, which governs email header format.

Even when the IP passes SPF, the From: domain mismatch due to display name encoding errors can lead to DMARC failure. This isn’t about the content of the message but about header consistency. The receiving system sees two different domains: one from the SPF check and one from the From: header.

Many tools catch this during pre-send checks, especially when validating list hygiene. If you're sending to a global audience with international names, always validate addresses—especially with special characters. Tools like our email checker surface these issues before you send, helping avoid delivery issues caused by alignment problems rooted in display name encoding.

Common scenarios where accent issues trigger alignment failures

When your From: display name includes accented characters like José or Münich, many email systems fail to properly encode or align the name with the domain in the sender's SPF record—resulting in a “SPF pass but alignment fails” error. This occurs because the display name’s UTF-8 encoding isn’t preserved or normalized across systems, breaking DMARC alignment even when authentication passes. You’re sending correctly, but the mailbox provider sees an unaligned sender. The fix starts with standardizing display name encoding before sending.

Real-world cases where accents cause alignment issues

  • Using non-ASCII names like Cécile or Andrés in your From: field during localized campaigns—especially when automated tools don’t sanitize or encode the name properly.
  • Relaying or forwarding emails through systems with different default encodings (e.g. legacy SMTP servers or older email clients that strip or corrupt UTF-8), which alters how the display name appears to DMARC validators.
  • Automated workflows that generate From: headers from user input without converting UTF-8 to properly encoded display strings—common in form-to-email pipelines or CRM integrations.
  • International campaigns using multilingual display names where the email client or MTA strips or misrepresents non-ASCII characters during transport—making the domain in the From: field appear mismatched to SPF.

Why standards don’t always help

While RFC 5322 and RFC 6532 define UTF-8 support for email headers, not all systems enforce or interpret them consistently. Some MTAs still default to ISO-8859-1 or even shift-JIS, especially in older environments. Even when your mail server supports UTF-8, the receiving system’s handling of display name encoding may still fail DMARC alignment checks.

One study found that around 12% of DMARC alignment failures in global enterprise email flow stemmed from display name formatting errors—many tied to unescaped or misencoded Unicode characters. This doesn’t mean your SPF is broken, but it does mean your messages may get marked as suspicious.

If you’re automating sender headers from user data, test each address with a reliable email verification tool before sending. You can check the exact encoding and delivery viability of an address using MailTester’s real-time email checker, which validates not just syntax but deliverability risk—even in multilingual or accented contexts.

How to prevent alignment failures with accent-rich display names

Use only ASCII characters in the display name part of the From: header for outbound campaigns. Accented characters like é, ñ, or ü can cause alignment failures during DMARC checks, even if SPF passes. Normalize names before sending—'José' becomes 'Jose'—to ensure consistent parsing across email systems. Let’s fix this at the source so your emails land in inboxes, not quarantine.

Best practices for handling display names

  • Pre-encode or normalize names to ASCII before including them in the From: header. Tools like Unicode NFC normalization help convert characters like 'José' to 'Jose' without altering meaning.
  • Avoid relying on email clients or ESPs to auto-encode display names. Some platforms apply encoding inconsistently or incorrectly, especially in legacy email systems.
  • Test your From: header structure using a real-time verification tool that checks MIME formatting and alignment. This reveals hidden issues before sending to real users.
  • Safeguard against display name encoding quirks by using RFC 2047 compliant encoding only when required—typically when non-ASCII text is unavoidable and cannot be normalized.

Verify headers before sending

Even if SPF passes, misaligned display names break DMARC. This happens because DMARC checks the From: header’s domain alignment using the sender’s domain, not the display name. If the display name contains unprocessed UTF-8 characters, parsing can drift from expected outcomes.

For bulk campaigns, use an email checker that validates both the address and the header structure. You can test individual addresses with a real-time email checker or verify your entire list using bulk verification—each with full MIME inspection and alignment analysis.

How to validate From: header alignment during email send tests

You can validate From: header alignment during send tests by sending emails to an inbox-placement testing service that examines both SPF and DMARC policies. These services parse the raw MIME headers to check if the domain in the From: field aligns with the MAIL FROM domain, revealing issues like SPF pass but alignment fail—especially when display names include accented characters. Use tools that show the full header structure to catch discrepancies before they trigger rejection.

Check alignment in real-world conditions

  • Send test emails through your production email service or SMTP setup to services like Spamhaus’s reputation tools or third-party inbox placement testers that analyze full header structure.
  • Use an email testing tool that displays the raw MIME headers (like MailTester’s inbox placement checker) to inspect the actual values of the From: and MAIL FROM fields.
  • Compare the domain in the From: header (including any display names like "Médecins Sans Frontières") to the MAIL FROM domain used during SMTP session. A mismatch here causes DMARC alignment failure even if SPF passes.
  • Look for encoded display names: accents in display names often trigger UTF-8 encoding, changing how the email client parses the From: field. This can break alignment checks even when the domain is technically correct.
  • Test with tools that simulate real inbox environments—some senders pass validation in test scripts but fail in actual inboxes due to misaligned headers caused by character encoding.

Monitor alignment over time

  • If you receive DMARC reports (from organizations like Google, Yahoo, or through a third-party aggregator), use them to track alignment failures over time.
  • Map the From: domains in those reports to your MAIL FROM domains. Look for patterns: repeated failures on specific domains suggest a systemic misalignment.
  • Use reported data to validate whether your sender infrastructure consistently aligns With the From: domain, especially for international or multilingual lists.
  • Align your email sending setup with the actual domains you claim in the From: header—don’t rely on SPF alone.
  • Consider using MailTester’s bulk verification to screen your sending list for addresses that may trigger header issues, including those with problematic display names or rare character sets.
DMARC alignment isn’t just about the domain—it’s about how the email client interprets the From: field, especially with non-ASCII characters. Misalignment here can cause delivery issues even with valid SPF and DKIM.

How MailTester helps catch alignment issues early

You don’t need a DNS audit to spot alignment failures caused by accented display names. MailTester’s real-time API checks the full From: header—including MIME-encoded display names—so you catch alignment issues before sending. It flags non-ASCII characters in display names that break SPF alignment even when SPF passes, helping you avoid inbox placement risks. Let’s walk through how.

Check the full header, not just the address

  • MailTester verifies the complete From: header, including the display name and encoded MIME parts. This catches cases where SPF passes but alignment fails due to malformed or non-ASCII characters in the display name.
  • Unlike basic email validators, it parses the header as it’s meant to be interpreted—using RFC 5322 and RFC 6376 standards—to detect issues that only appear during actual email processing.
  • For example, a display name like “José García” encoded as =?UTF-8?B?Sm9zZ8OpIEdhcmFjaW8=?= in the header can cause alignment issues if the From: domain doesn’t match the sender’s domain, even when SPF passes.
  • Use the real-time API to validate individual addresses with full header context during development or integration testing.

Scan large lists for hidden alignment risks

  • With the bulk verification feature, you can scan entire mailing lists for From: header inconsistencies, including non-ASCII characters in display names that trigger alignment failures.
  • MailTester reports each address with a verdict—valid, invalid, catch-all, risky—alongside detailed notes on why alignment failed, even if SPF passed.
  • When you find a "risky" result due to display name encoding, you can trace it back to a specific list entry and fix the source data before sending.
  • Our in-app AI assistant explains why a verification failed—such as "Display name contains non-ASCII characters that do not align with the From: domain" or "MIME encoding mismatch." No guesswork.
  • By catching these issues at scale, you prevent entire campaigns from being flagged for authentication anomalies by receivers like Gmail or Outlook.
Alignment failures are common when display names aren’t properly encoded or don’t match the sending domain. Even when SPF passes, these mismatches reduce trust. The key is validating the complete header context.

Why ASCII-only display names are still the safest choice

Using only ASCII characters in your display name eliminates alignment failures caused by UTF-8 handling inconsistencies—especially when SPF passes but DKIM or DMARC alignment fails. Many email systems, particularly older or non-compliant ones, misinterpret or strip accented characters, leading to broken header validation even with valid SPF. If your system can’t parse the display name correctly, it can still reject or rewrite it, breaking alignment and risking deliverability.

Not all systems parse UTF-8 display names correctly

While RFC 6376 (which defines DKIM) allows UTF-8 in headers, not all MTAs honor it. Some legacy email servers or poorly configured systems will fail to decode accented characters, treat them as invalid, or silently strip them. This can cause the sender’s name in the header to diverge from the expected domain in SPF or DMARC checks, resulting in alignment failures even when the underlying authentication passes.

For example, a display name like “José Rodríguez” may arrive as “Joso Rodrguez” or be stripped entirely. Even if SPF validates, the mismatch between the sender origin and the rewritten display name can trigger alignment checks to fail, especially on domains enforcing strict DMARC policies.

ASCII ensures consistent, predictable behavior

Using only ASCII characters—letters A–Z, a–z, digits, and basic punctuation—guarantees compatibility with every major inbox provider, including Gmail, Outlook, Yahoo, and Apple Mail. No system needs to interpret or decode non-ASCII data when it’s not present. It’s not just about avoiding bugs; it’s about removing variables in a process where one inconsistency can affect inbox placement.

Even if SPF passes, a display name that breaks alignment or triggers rewriting can signal ambiguity to spam filters. Some systems flag such anomalies as potential spoofing attempts—especially if the display name appears to be crafted to mimic a trusted sender. By sticking to ASCII, you avoid the risk of being flagged for suspicious behavior, even if the technical authentication is sound.

Still, you can test how your messages behave in real environments. Use inbox placement testing to see how your messages land across major inboxes, including header inspection and alignment behavior. For ongoing list hygiene, verify your email addresses at scale with bulk verification or test individual addresses with our email checker. Consistent header integrity starts with simple, predictable data.

What to do if you must use accented characters in From: headers

You must encode the display name in the From: header using RFC 2047-compliant format—like =?UTF-8?Q?Jos=E9?=—and ensure your email library handles this correctly across all platforms. Never assume SPF pass means the message will deliver; alignment must also pass. Test every send with full header inspection in a controlled environment before mailing to production lists.

Use correct encoding from the start

  • Always wrap display names with accented characters in =?UTF-8?Q?...?= format. This is mandated by RFC 2047, the standard for encoding non-ASCII text in email headers. Without it, receivers may reject or misrender the display name, breaking alignment checks.
  • Use a standardized email library such as PostgreSQL's pg-promise or PHP's mb_encode_mime_header—both correctly implement RFC 2047 at the language level and reduce encoding errors.
  • Manually testing with tools like MxToolbox or Mail-Tester can help you verify that the header appears correctly in the raw source—look for the full =?UTF-8?Q?...?= sequence in the From: field.

Test and validate before sending

  • Never rely solely on SPF pass as confirmation of deliverability—SPF only validates the sending server’s identity, not the From: header’s content or alignment. DMARC alignment requires that the domain in the From: header matches the domain used in SPF and DKIM.
  • Test every sending workflow in a staging environment with full header inspection. Use tools like MailTester’s inbox placement tester to simulate real inbox conditions and catch alignment issues before they impact your sender reputation.
  • Verify your list before sending using MailTester’s bulk verification to catch invalid or misformatted addresses that might otherwise trigger alignment failures or spam complaints.
Encoding isn’t optional. It’s a required step to ensure your email appears correctly across all clients and passes DMARC alignment checks. Skip it, and you risk rejection, reduced inbox placement, or flagged content.

When in doubt, decode the raw headers of a real sent email and compare them with your outbound message. If the display name is rendered as plain text or broken, the alignment check will fail—even with valid SPF. Use consistent tools, validate every step, and never trust a “pass” without full header inspection.

How to measure the impact of alignment failures on deliverability

If your emails have accented characters in the display name and fail SPF alignment, you’re risking inbox placement—even if SPF passes. Track inbox placement, bounce rates, and spam complaints over time. Use DMARC reports to compare campaigns with and without accent-rich names, and validate message authenticity with tools like MxToolbox or Spamhaus.

Monitor real-world delivery metrics

  • Run A/B tests using the same content, but vary the display name: one with accented characters, one without. Monitor inbox placement rates for each.
  • Check your ESP’s delivery reports for spikes in hard bounces or filtering (especially to Gmail or Outlook) after deploying messages with non-ASCII display names.
  • Use Spamhaus to verify whether incoming messages with problematic headers are being flagged due to alignment mismatches.
  • Set up daily spam complaint tracking—some mailbox providers penalize misaligned headers even when the message isn’t malicious.

Analyze DMARC and third-party diagnostics

  • Review DMARC aggregate reports (RUA) from your domain to isolate failures tied to display name alignment, not just email address or SPF.
  • Compare results across campaigns: are messages with accented names showing higher failure rates in DMARC reports?
  • Use MxToolbox to check the full header chain of a delivered message—verify whether alignment is failing at the "From" header level due to encoding issues.
  • Run the same email through MailTester’s inbox placement tester to simulate how different providers handle the header.
  • Validate your full email structure—especially the From header and display name encoding—by testing individual addresses via the email checker.
Even when SPF passes, a misaligned From header can trigger rejection or filtering—especially in strict DMARC policies.

Let’s not assume technical compliance equals inbox success. Focus on how actual behavior changes when you use non-ASCII characters. The real test isn’t whether the header parses—it’s whether the message lands where it should. Use real metrics, not just validation scores.

Final takeaway: SPF pass doesn’t equal deliverability

SPF pass means the sending server is authorized, but it doesn’t guarantee inbox placement. Alignment failures can still occur if the From: header contains non-ASCII characters, even with valid SPF and DKIM.

Authentication checks only one layer of email delivery. A technically valid setup can still fail due to malformed headers, misconfigured display names, or domain policies.

What to do next

  • Verify the full From: header structure, not just SPF or DKIM status.
  • Ensure display names use only ASCII characters to avoid alignment issues.
  • Test deliverability with real inboxes using tools that simulate recipient behavior.

Sources

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Does SPF check the display name?

No. SPF only validates the MAIL FROM domain. It ignores display names entirely.

Can accented characters in a display name break DMARC alignment?

Yes. When not properly encoded, accented characters can cause parsing mismatches that fail alignment.

Why does my email pass SPF but fail alignment?

SPF checks the sending IP, but alignment checks if the domain in the From: header matches the MAIL FROM domain. Mismatches break alignment.

Are non-ASCII display names safe to use?

Not reliably. Many email systems handle them poorly, leading to formatting errors or alignment failures.

How can I test if my From: header is causing alignment issues?

Use inbox-placement testing tools or MailTester’s real-time API to inspect full headers and identify parsing problems.

What’s the safest display name format for email campaigns?

Stick to ASCII-only characters. Names with accents should be normalized or encoded using RFC 2047.

Does Gmail detect alignment failures from accented names?

Yes. Gmail uses DMARC alignment to assess authenticity, and misaligned headers can trigger spam filtering.

Can I fix alignment issues after the email is sent?

No. Once sent, you cannot fix header issues. Prevention through testing is required.

How accurate is MailTester at spotting alignment issues?

MailTester has 98.9% accuracy in verifying email addresses and diagnosing deliverability risks, including header alignment problems.

Do I need to pay to test alignment issues?

No. You can start with 100 free verifications to test your From: headers and alignment settings.

Can MailTester help with bulk campaign verification?

Yes. MailTester’s bulk verification scans entire lists, catching invalid, catch-all, and high-risk addresses before sending.

What’s the difference between email verification and deliverability testing?

Verification checks if an address exists and accepts mail; deliverability testing checks how likely it is to land in the inbox, including alignment, reputation, and spam filter behavior.