How do I fix Apple Mail DMARC failure when sending from Gmail with a non-Gmail domain?
Published 13 Jun 2025
Updated 11 Oct 2026
15 min read
Summarize with
Updated on 11 Oct 2026: We clarified Google SMTP sign-in and how to confirm that Apple Mail passes DMARC for a custom domain.
Fix this by making Apple Mail send the non-Gmail address through an SMTP service authorized to send and authenticate mail for that domain. For a Google Workspace domain, select the matching Workspace account. For a domain hosted elsewhere, use that mail provider's authenticated outgoing server. In the failure pattern, the visible From address uses a custom domain, but the Return-Path and SMTP authentication use a Gmail address. SPF passes for Gmail, but it does not match the From domain. The message also lacks a passing DKIM signature that matches the custom domain. DMARC fails because neither SPF nor DKIM passes with a domain match to the From domain.
The fastest practical fix starts in Apple Mail account settings. Select the custom-domain account and change its outgoing mail server to the SMTP account for that address. If Apple Mail selected another Gmail SMTP server after a send error, switch the outbound server dropdown back to the right account. Then send a fresh test email and inspect the Authentication-Results header.
A Gmail rejection with SMTP code 5.7.26 needs the full bounce text to diagnose it. A reason that names the domain's DMARC policy points to a DMARC failure; the same code also covers missing authentication and SPF hard-fail rejections. See Google's SMTP error reference. If the message was rejected, use the bounce details and a fresh test to a separate mailbox that accepts it, then inspect the received Authentication-Results header.
- Direct fix: Match the Apple Mail From address with an SMTP account that authenticates the same domain.
- Main symptom: Authentication-Results says DMARC failed for the custom domain while SPF passed for a Gmail address.
- Common trigger: Apple Mail asks to use another outgoing server, then keeps sending that identity through the wrong Gmail account.
- Best confirmation: A new test message shows SPF or DKIM matching the custom From domain.
Why Gmail SPF can pass while DMARC fails
DMARC checks whether passing SPF or DKIM authenticates a domain that matches the visible From header. In this failure mode, Apple Mail composes the message as user@example.com, but it authenticates to Gmail SMTP as user@gmail.com. Gmail then sends the message using the Gmail account as the envelope sender. The receiver sees SPF pass for Gmail, but the visible From domain is the custom domain, so SPF does not match. SPF uses the SMTP MAIL FROM domain, not the SMTP login username. Under relaxed aspf=r, the organizational domains must match; strict aspf=s requires an exact domain match.
DKIM provides a DMARC pass when a standard DKIM-Signature verifies and its signing domain matches the visible From domain. X-Google-DKIM-Signature with d=1e100.net is a separate Google transport header, not a standard DKIM-Signature used for DMARC. A standard signature with d=gmail.com also fails the domain match for example.com. DMARC needs a passing DKIM signature whose d= domain has the same organizational domain as the visible From address under relaxed alignment. Strict adkim=s requires an exact domain match.
A published DKIM key does not prove a message passed
A DNS DKIM lookup confirms that a public key exists. It does not prove that the sending service signed this message or that the signature verified. DMARC fails when the actual message has neither a passing domain-matched SPF result nor a passing domain-matched DKIM result.
Illustrative failed message header excerpttext
Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=user@gmail.com; dkim=pass header.d=gmail.com; dmarc=fail header.from=example.com Return-Path: <user@gmail.com> From: User <user@example.com> X-Google-DKIM-Signature: d=1e100.net; ...
That header pattern points to the sending path, so fix the path before editing the DMARC policy. A stricter or looser DMARC policy only changes the domain owner's requested handling for a failed message. It does not make authentication match the From domain, and receivers can still apply local filtering.
Check the received message headers
Start with the headers of a message delivered to a separate recipient mailbox. They show the actual sending identities and authentication results. Google also has a DMARC troubleshooting page for Workspace administrators.
In the recipient's Gmail inbox, open the test message, select More beside Reply, then Show original to see the full headers. Follow Google's header instructions. Read the Authentication-Results added by the receiving mailbox provider; the copy in your Sent folder does not show the final receiver's checks.
- Visible From: Find the domain in the From: header. This is the domain DMARC protects.
- Envelope sender: Check Return-Path and smtp.mailfrom. If they show a Gmail address, SPF will not match the custom From domain.
- DKIM domain: Look for DKIM-Signature and its d= value, then confirm the receiver reports dkim=pass for that domain. A Google transport header alone does not authenticate the custom From domain.
- DMARC result: Read the receiver's Authentication-Results line. It usually states the DMARC result and the domain that failed.
Wrong path
- From header: Custom domain address.
- SMTP login: Personal Gmail credentials.
- SPF result: Passes for Gmail, no match.
- DMARC result: Fails for the custom domain.
Correct path
- From header: Custom domain address.
- SMTP login: Account authorized for that domain.
- Auth result: SPF or DKIM matches the From domain.
- DMARC result: Passes through the matching method.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Select the correct outgoing account in Apple Mail
Apple Mail is the mail client. It needs an outbound SMTP server to send the message. If the wrong outbound server is selected, the message can keep the original custom-domain From address while authenticating through a different Gmail account. DMARC fails if neither SPF nor DKIM authenticates a domain matching that From address.
Apple Mail Server Settings with the Work Workspace outgoing account selected.
- Open settings: In Apple Mail, choose Mail, Settings, Accounts, then select the custom-domain account.
- Check server settings: Open Server Settings, use the outgoing Account menu, then choose Edit SMTP Server List to inspect the login and host name. Click OK to save any edited server entry.
- Select the right sender: Choose the Google Workspace account or provider SMTP account that belongs to the custom-domain address.
- Detach the wrong fallback: Stop the custom-domain account from using personal Gmail SMTP. Remove that server entry only if no other Apple Mail account uses it.
- Send a new test: Send a fresh message to a separate recipient mailbox and inspect the headers as received. Test the From address you actually use, including an alias if applicable.
Check the outgoing account after a send error
If Apple Mail cannot send through the account's SMTP server, it can ask to use another server. Choosing a personal Gmail server there can preserve the custom-domain From address while sending with personal Gmail credentials. The send appears successful, but authentication no longer matches.
Give each outbound account a clear description, such as "Work example.com" instead of a generic "Gmail" label. Apple Mail displays that description in its server menus, which helps prevent the same mistake later. These settings are documented in Apple's outgoing server settings.
If Google rejects the SMTP sign-in
Fix the Google account connection before selecting another outgoing server. A 535 error or repeated password prompt concerns SMTP sign-in, before the recipient evaluates DMARC. It is separate from a later 550 5.7.26 delivery rejection.
- In Apple Mail, choose Mail, Add Account, select Google, and sign in to the full Google Workspace user address. Complete the browser authorization so Mail uses OAuth.
- Select that Workspace account for the custom-domain sender in Server Settings. If Google sign-in still fails, ask the administrator to check whether the client is allowed to access the account.
Current Apple Mail supports OAuth, so use the Google account option instead of entering a normal Google password into a manually configured SMTP login. See Google's Apple Mail setup.
|
|
|---|---|
Host | smtp.gmail.com |
Secure connection | 587 with STARTTLS or 465 with SSL/TLS |
Login | Full Workspace user address, not a personal Gmail address |
Google Workspace SMTP submission settings.
The Google SMTP settings use the same host for personal Gmail and Workspace. The host name alone does not prove you selected the right account. An authorized Workspace alias has no separate login; authenticate as its owning user and verify the alias's domain in the received message.
If a manual setup cannot use OAuth, an app password requires 2-Step Verification and must be permitted for the account. It authorizes the connection, not DMARC authentication for another domain. Google revokes app passwords after a Google account password change; replace a revoked app password rather than switching to personal Gmail SMTP.
If the domain does not use Google Workspace
A non-Gmail From address is not necessarily a Google Workspace address. If the custom domain's mailbox is hosted by another provider, configure Apple Mail to use that provider's authenticated SMTP server. A personal Gmail login authorizes Gmail sending, but it does not give Gmail a custom-domain DKIM key or make a gmail.com envelope sender match the custom From domain. Adding include:_spf.google.com to the custom domain's SPF record does not repair a message whose smtp.mailfrom is gmail.com. SPF checks the envelope sender's domain, so that message uses Gmail's SPF record.
Gmail's web-based "Send mail as" entry and Apple Mail's outgoing server are separate configurations. Messages composed in Apple Mail use the outgoing server selected in Apple Mail. Editing the alias in Gmail on the web does not change that desktop setting. Google has announced that third-party "Send as" support ends in January 2027. Google-hosted Gmail identities and Workspace aliases are excluded from that change. Apple Mail can still send directly through the custom domain's provider SMTP server.
- Get the provider settings: Use the SMTP host name, port, TLS option, and username issued for the custom-domain mailbox.
- Configure Apple Mail: Add or edit that server in the SMTP Server List, then select it for the custom-domain account.
- Authorize the service: Publish the SPF record and DKIM key required by the provider that actually sends the mail.
- Verify the received message: Confirm that SPF or DKIM passes and matches the domain in the visible From address.
When the domain has no SMTP service
A forwarding-only address does not automatically include a valid outgoing service. If the domain provider offers no authenticated SMTP option, use a mail service that can send for the custom domain and provide domain-matched SPF or DKIM. Do not route the address through personal Gmail SMTP and expect the display name or From alias to create DMARC authentication.
Fix Google Workspace authentication
After the Apple Mail outbound account is corrected, confirm Google Workspace is configured to authenticate the domain properly. Gmail should send for the authorized Workspace user and authenticate the visible From domain. For an alias on a different domain, do not assume the primary account's SPF or DKIM result matches the alias. Enable DKIM for the alias's sending domain and verify the actual received result.
|
|
|
|---|---|---|
SMTP | Workspace user authorized for the sender or alias | Personal Gmail login |
SPF | SPF pass with a matching MAIL FROM domain | Passing SPF for gmail.com or an unrelated primary domain |
DKIM | DKIM pass with a matching d= domain | Google transport signature only |
DMARC | SPF or DKIM passes with a domain match | Both matching methods fail |
Google Workspace authentication checklist.
If DKIM is missing for the custom domain, open Apps, Google Workspace, Gmail, Authenticate email in the Admin console. Select the domain used in the From address, generate or confirm its key, publish the selector TXT record in DNS, then click Start authentication. Repeat the setup for each sending domain. Follow Google's DKIM setup. Allow for DNS caching, then send a fresh test to a separate recipient and confirm dkim=pass with a DKIM-Signature whose d= domain matches the visible From address under the domain's alignment mode.
For authorized Google Workspace sending, add include:_spf.google.com to the domain's existing SPF record alongside its other legitimate senders. Publish one v=spf1 record per domain, rather than adding a second SPF record. Follow Google's SPF setup.
Illustrative monitoring record for a new DMARC setupdns
_dmarc.example.com. 3600 IN TXT ( "v=DMARC1; p=none; rua=mailto:dmarc@example.com; " "adkim=r; aspf=r" )
A p=none policy requests monitoring. It does not repair domain alignment or guarantee inbox delivery. If the domain already uses p=quarantine or p=reject, do not weaken it merely to hide this symptom. Fix the sending source and confirm it in reports before changing enforcement. Suped's DMARC monitoring workflow groups failures by source and shows whether SPF or DKIM provides domain alignment for each sender.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
How to prove the fix worked
The fix has worked when a new message sent through Apple Mail shows a domain-matched SPF pass or a domain-matched DKIM pass for the custom From domain. DMARC needs only one passing method with domain alignment. Keeping both SPF and DKIM healthy gives normal domain mail two valid authentication paths. Send directly to the test recipient first. Forwarding can change the envelope sender and break SPF, so a surviving, domain-matched DKIM signature is especially useful. A DMARC pass confirms authentication; it does not guarantee inbox placement.
Apple Mail DMARC flowchart showing Workspace SMTP with matching SPF and DKIM domains.
Illustrative successful header with both SPF and DKIM passingtext
Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=user@example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com Return-Path: <user@example.com> From: User <user@example.com>
If the new header still fails DMARC, separate the failure into two questions. First, is Apple Mail using the right outbound account? Second, is the selected service signing or sending with a domain match for that domain? The answer is usually visible in one or two header lines.
- Still Gmail mailfrom: If DKIM also lacks a passing custom-domain signature, check the SMTP credentials and outgoing server entry. A gmail.com envelope sender alone does not cause DMARC failure when matching DKIM passes.
- No DKIM signature: Domain DKIM signing is not enabled, DNS is not published, or the message did not pass through the intended sending service.
- DKIM passes elsewhere: The DKIM signature is valid, but its signing domain does not match the visible From domain.
- Receiver rejects: Read the full rejection reason before assuming it is DMARC. If it names the domain's policy, fix the authentication source before considering a policy change.
For broader troubleshooting, this closely relates to cases where SPF and DKIM pass but DMARC still fails because the authenticated domain is not the domain the recipient sees in the From header.
Monitor the sending source in Suped
Suped is our DMARC reporting and email authentication platform. Its aggregate reports identify sending sources and show whether SPF or DKIM domain alignment passed, along with the domain policy the receiver evaluated.
For this workflow, Suped groups authentication failures by source and provides fix steps. Compare the Google sending sources before and after changing Apple Mail's outgoing account.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Google sending IPs appear in reports for both personal Gmail and Workspace, so an IP alone cannot identify the account Apple Mail used. Diagnose that choice with individual message headers, then review later reporting periods in Suped to confirm the source's DMARC pass rate. Aggregate reports are delayed and do not identify the Apple Mail client.
- Review the failing source and compare its SPF and DKIM domains with the custom From domain.
- Use received headers to connect the reported failure pattern to the Apple Mail outgoing account.
- Compare later reporting periods after the SMTP correction to check that legitimate traffic passes.
- Keep reporting active while quarantine or reject remains in place to catch recurring failures.
Views from the trenches
Best practices
Name each outbound account by domain so users can select the right SMTP server quickly.
Confirm headers after every Apple Mail account change, using a fresh message each time.
Keep Workspace DKIM enabled so domain signing protects mail when SPF matching changes.
Common pitfalls
Treating a Google transport DKIM signature as proof that the From domain is signed.
Changing the DMARC policy before first confirming which SMTP account Apple Mail used.
Leaving personal Gmail as a fallback server for business-domain mail in Apple Mail.
Expert tips
Read smtp.mailfrom before SPF conclusions; it usually reveals the wrong account fast.
Use a second mailbox test when a receiver gives sparse authentication failure details.
Check Apple Mail's outgoing dropdown after any send error or account password change.
Marketer view
Marketer from Email Geeks says the header pattern showed Apple Mail sending the custom From address through a personal Gmail account, which made DMARC fail.
2025-01-22 - Email Geeks
Marketer view
Marketer from Email Geeks says Apple Mail can prompt users to choose another SMTP server, and that choice can keep causing failures until the outbound account is corrected.
2025-01-23 - Email Geeks
Check replies and sender aliases
After correcting the outgoing account, test both a new message and a reply using each custom-domain From address you send with. Confirm the received message passes DMARC, keep reporting active, and recheck the selected SMTP account after another send error.
Frequently asked questions
It is usually an account routing problem in Apple Mail. The selected SMTP service sends using the credentials Apple Mail provides, so the wrong outgoing account creates a mismatch between the authenticated domain and the custom From domain.
SPF can pass for the Gmail envelope sender while DMARC fails for the custom From domain. DMARC requires SPF or DKIM to pass with a domain match to the visible From domain.
No. X-Google-DKIM-Signature is a separate transport header, and a standard DKIM signature with d=gmail.com does not match a custom From domain. The passing DKIM signature needs a signing domain that matches the domain in the visible From address under the domain's alignment mode.
No, not as the first fix. A p=none policy requests monitoring but does not repair SPF or DKIM domain alignment, and it does not guarantee delivery. Correct the outgoing server and verify a fresh message before changing enforcement.
Configure Apple Mail with the authenticated SMTP server for the provider that hosts or sends mail for the custom domain. That provider must support SPF or DKIM using a domain that matches the visible From address.
Send a new message from Apple Mail to a separate recipient mailbox and inspect that receiver's headers. Confirm DMARC passes for the custom From domain. The successful result should show matching SPF, matching DKIM, or both.
