The website screen does not reveal the mail route
A contact form can hand mail to local server software, a hosting relay, a mailbox account, an API service or a queue worker. A shop may use one provider for receipts and another for password resets. The From address visible in the application settings tells you almost nothing about the connecting host and authenticated domains.
The common mistake is to add the web server IP to SPF or change the root domain after looking only at the form. That can authorise the wrong host, expose a shared server or leave the real relay untouched. Trace a message from the production action to receiver evidence first.
Treat each application message type as a route with an owner, transport, envelope identity, signing identity and fallback behaviour. This reframe turns “website email is broken” into a bounded configuration question.
Map where the message is created and handed off
For each form, shop, booking system and application, record the component that creates the message, the library or service that submits it, the host or API endpoint that accepts it, the account used, the queue or retry owner and the final outbound provider. Include staging and scheduled jobs if they can use the production domain.
Ask whether the application uses SMTP with a mailbox credential, a provider API, the host’s local mail function or a managed ecommerce integration. Do not copy passwords into the route map. Record the secret location and owner, then verify least access through the relevant system.
Check logs for a test identifier and UTC time. Application “sent” often means only that the first hand-off succeeded. Follow the event through the outbound provider and receiving mailbox before calling it delivered.
Choose visible addresses that real people and systems can handle
Use a From domain you control and an address appropriate to the message. Set Reply-To to a monitored mailbox when replies are expected. Avoid using a visitor’s address in From, because the application is not authorised to send as the visitor’s domain and modern authentication will expose the mismatch.
For a contact form, keep your domain in From and place the submitted address in Reply-To only after validation and safe encoding. For receipts and account messages, use stable functional addresses with monitored bounce and support ownership. Do not put untrusted form text directly into message headers.
Separate transactional and marketing routes when their owners, permission handling, risk or sending patterns differ. Separation is useful only if the resulting domains and accounts are maintained; unnecessary subdomains create more records to forget.
Trace the envelope before changing SPF
SPF checks whether the connecting client is authorised to use the MAIL FROM or HELO domain. RFC 7208 defines the SMTP identities and authorisation process. The relevant policy belongs to the observed envelope domain, not automatically to the website’s public domain.
Send a controlled message and record Return-Path or trusted receiver evidence plus the source recorded by the provider. If a managed relay uses its own envelope domain, adding the website host to your root SPF record will not affect that result. If the service supports a custom return-path subdomain, configure it through account-specific instructions and verify the public delegation.
Keep one SPF record at each owner name and assess nested DNS lookups before merging a provider include. Do not authorise an entire hosting range merely because one application runs there.
If another system changes the route after the application hands the message over, forwarding and mailing-list authentication failures show what to compare at both observation points.
Configure DKIM at the system that signs
DKIM is applied by a signer that holds a private key, and receivers retrieve the public key using the d= signing domain and s= selector. RFC 6376 defines this signing and verification mechanism. Publishing a key cannot make an application sign if the outbound service has not enabled signing.
Find whether the application, relay or API provider is the signer. Generate or request a distinct selector using that system’s current account workflow. Publish only the public key or supported CNAME. Keep the private key in the authorised service and include rotation and retirement ownership in the route record.
After enabling it, inspect a received message. Confirm DKIM pass and copy the signing domain. If verification fails, query the exact selector and separate missing DNS from changed content. A gateway that appends or rewrites material after signing may own the failure.
Use DMARC to check the visible identity
DMARC compares the visible Author Domain with the SPF-validated MAIL FROM domain or a valid DKIM signing domain. One passing aligned path can produce a DMARC pass. RFC 9989 defines this comparison. A platform-domain pass is not enough when it does not align with your application’s From domain.
For many managed application routes, aligned DKIM is the clearest path because the provider can sign with a delegated business domain while keeping its delivery infrastructure. A custom return path can supply SPF alignment too. The exact choice depends on provider support and your ownership model.
Google recommends authenticating the domain that hosts a public website and requires sender authentication for mail to personal Gmail accounts. Google’s current sender guidance states these expectations. That recommendation still requires testing the actual route; a root DNS record cannot prove an application used it.
See also what DMARC checks and tracing a Gmail 550 5.7.26 rejection when a receiver names a specific failure.
Test the user action and the failure path
- Create a unique authorised event. Submit the real form or transaction with a recognisable non-sensitive test reference.
- Follow application and provider logs. Record creation, hand-off, queue state and receiver response with UTC times.
- Inspect the received original. Compare From, Reply-To, Return-Path, DKIM domains and authentication results.
- Exercise a controlled failure. Use a safe invalid test destination only where the provider permits it, then confirm bounce ownership and suppression behaviour without involving a real third party.
- Check retry and duplication. Make sure the application does not send a second copy while the first remains queued.
- Repeat another application route. Detect shared configuration that changed unintentionally.
Success includes the business outcome: the intended recipient path, support reply handling and operational logs agree. An authentication pass alone does not prove the booking, order or request reached the responsible team.
Keep form data out of the technical trace
Build the trace around an artificial test reference and UTC times, not a real customer submission. Keep the route map, queue event IDs, provider responses, DNS answers and redacted received header in the application incident area. Remove form text, order details, reset links, names and complete addresses from the working copy. The mail administrator usually needs the domains and verdicts, while the developer needs event and queue states.
Application logs can be more sensitive than a header because they may contain request bodies, tokens or stack details. Restrict raw logs to the service owner and copy only the event lines needed to show creation, hand-off, retry and provider response. When the outbound provider assists, use its authenticated support channel and provide its message ID plus the minimum redacted trace.
SMTP passwords, API keys, signing private keys and DNS recovery codes must remain in the secret-management system. Reference their owner and rotation status without copying the value. If a safe synthetic event cannot reproduce the issue and using a real customer record would widen access, stop and ask the application data owner to approve a controlled investigation.
Trace one application event all the way to the receiver
Trigger the exact production action with a unique, non-sensitive reference: submit the form, create the test order or request the account message. Follow that reference through application creation, queueing, relay or API acceptance and the provider’s receiver response. At a mailbox you control, inspect From, Reply-To, Return-Path, DKIM domains and authentication results, and compare every timestamp with the route map.
The result is complete only when the business event, transport logs and received message agree. Test a permitted failure path with a reserved or provider-approved invalid destination, then confirm that the bounce reaches the right owner and does not cause endless retries. Check for duplicate delivery while the original event remains queued. Repeat another application message type if it shares the relay or DNS records.
Save the redacted trace, public DNS answers and receiver header under the event reference. A DNS checker cannot show that the application selected the intended account or signing domain. If the message authenticates but disappears in an internal support queue, record that operational fault separately rather than calling the whole journey successful.
Stop when the fault crosses application boundaries
Pause configuration changes if the outbound service cannot be identified, logs disagree about whether a message left the queue, a proposed SPF record would authorise a whole hosting range, or the DKIM selector belongs to another application. Stop the affected job if retries create duplicates or a production transaction begins failing after the change.
Give the application owner the event trace, the hosting or queue owner the hand-off evidence, and the outbound mail service the provider ID and redacted header. The DNS administrator should receive only the exact observed envelope or signing name and the saved baseline. Use the isolated rollback when its approval conditions are met.
Do not rotate domains, weaken DMARC or share credentials to bypass the failure. Resume once one team owns each boundary, the intended identity is visible in a controlled message and the retry or duplicate risk has been cleared.
Sources and further reading
- Google email sender guidelines
- RFC 7208: Sender Policy Framework
- RFC 6376: DomainKeys Identified Mail signatures
- RFC 9989: Domain-based message authentication, reporting and conformance