How To Configure SPF For Native Email Sending

When an application sends email through its own SMTP server or relay rather than handing delivery to an email service provider, it is responsible for proving that its sending infrastructure is authorised to use the domain. SPF is part of that proof.

SPF, or Sender Policy Framework, is a DNS-based authorisation record. It tells receiving mail systems which IP addresses and services may send mail using a particular envelope sender domain. For native sending, the important question is not simply “what address appears in the From header?” It is: which system makes the final SMTP connection to the recipient, and which domain does it use in SMTP MAIL FROM?

Get that relationship right before editing DNS. A syntactically valid SPF record can still fail if it authorises the wrong server, sits on the wrong domain, exceeds SPF lookup limits or does not align with the visible From domain for DMARC.

What SPF checks in a native sending setup

Email has more than one sender identity. These are commonly confused:

• From: the visible address in the message header, such as updates@example.com. This is the address recipients see.
• MAIL FROM: the SMTP envelope sender, often called the return-path or bounce address, such as bounce@example.com. Delivery failures are normally sent here.
• EHLO or HELO name: the hostname presented by the SMTP client when it opens a connection, such as mail.example.com.
• Sending IP address: the public IPv4 or IPv6 address that actually connects to the recipient’s mail server.

SPF primarily evaluates whether the connecting IP address is authorised by the domain used in MAIL FROM. Receivers can also evaluate the EHLO/HELO identity. The SPF standard recommends checking both, and requires a receiver to check MAIL FROM if the HELO check has not produced a decisive result. RFC 7208, the SPF specification describes these identities and the evaluation rules.

For a native application, the application host itself may not be the relevant sending machine. For example, an application on a private network might submit messages to Postfix, Exim, Exchange or a cloud virtual machine. If that relay connects directly to Gmail, Microsoft 365 or another recipient service, its public egress IP address is the one that must be authorised. If traffic passes through NAT, authorise the NAT’s public IP, not the application’s private address.

Start with a sending-path inventory

Do not begin by copying a generic SPF value. List every legitimate system that can originate mail using the envelope domain. This normally includes more systems than expected:

• the production application’s transactional mail relay;
• separate infrastructure for password resets, receipts and account alerts;
• servers used by support or operations teams;
• Microsoft 365 or Google Workspace, if staff mail uses the same domain;
• marketing, survey, helpdesk, billing or CRM platforms that use a custom return-path;
• disaster-recovery infrastructure and alternate regions; and
• IPv6 egress addresses, where they are enabled.

For each path, record the MAIL FROM domain, the final public sending IP or provider-authorisation instruction, the EHLO name, and whether DKIM is applied. A server that is allowed to send internal test messages may still need to be included if it sends to external recipients.

At the same time, remove old senders. SPF is an allow-list: a forgotten IP address, retired hosting provider or obsolete application left in the record remains authorised to impersonate the envelope domain. This is one reason SPF should be reviewed whenever mail infrastructure changes.

Choose the right envelope sender domain

For straightforward transactional mail, a common arrangement is:

Visible From:     notifications@example.com
SMTP MAIL FROM:   bounces@example.com
EHLO hostname:    mail.example.com
Sending IP:       198.51.100.24

In this example, publish the principal SPF record at example.com, because SPF evaluates the domain in bounces@example.com. The local part, bounces, does not affect the SPF lookup.

Many organisations instead use a dedicated subdomain for the envelope sender:

Visible From:     notifications@example.com
SMTP MAIL FROM:   bounce.mail.example.com
EHLO hostname:    smtp1.mail.example.com
Sending IP:       198.51.100.24

That design separates delivery and bounce handling from ordinary staff mail. In this case, the SPF record belongs at mail.example.com, because that is the domain following the @ in the MAIL FROM address. It can make operational ownership clearer, but it adds DNS records and must be planned alongside DMARC alignment.

Under DMARC’s default relaxed SPF alignment, bounce.mail.example.com can align with a visible From address at example.com, because both share the same organisational domain. Strict SPF alignment requires an exact domain match. The formal distinction is explained in RFC 7489’s DMARC alignment rules.

Using a different organisation’s domain in MAIL FROM is usually a poor fit for native sending. Even if SPF passes for that other domain, it will not provide SPF alignment for mail visibly sent from example.com. Configure a bounce domain you control and authenticate it deliberately.

Build the SPF record

SPF is published as a DNS TXT record. A native sender with one fixed IPv4 address might use:

Host/name: @
Type:      TXT
Value:     v=spf1 ip4:198.51.100.24 -all

@ means the zone apex at many DNS providers; some interfaces ask for the bare domain name or leave the name field blank. The example IP is documentation-only. Replace it with the actual public address used by the outbound SMTP service.

The mechanisms mean:

• v=spf1 identifies the record as SPF version 1.
• ip4:198.51.100.24 authorises that one IPv4 address.
• -all says that all other sources should fail SPF.

If the server sends from IPv6 as well, authorise the specific address or network that is genuinely under your control:

v=spf1 ip4:198.51.100.24 ip6:2001:db8:1234:5678::25 -all

Do not add broad network ranges merely to avoid future DNS edits. SPF should express the smallest practical set of authorised senders. A narrow record reduces accidental authorisation and makes investigation easier when an unfamiliar sending IP appears in DMARC reports.

When to use include

Use include: only when another provider explicitly instructs you to do so. It tells receivers to evaluate that provider’s SPF policy as part of yours. For example, an organisation using Microsoft 365 for staff mail alongside a native transactional server could have a record resembling:

v=spf1 ip4:198.51.100.24 include:spf.protection.outlook.com -all

Use the provider’s current documentation rather than treating this example as universal. Microsoft’s guidance confirms that a domain has one SPF record, which may contain several authorised mechanisms, and gives examples for combining Microsoft 365 with on-premises or third-party senders. See Microsoft’s SPF DNS guidance.

Do not publish one SPF TXT record for the native server and a second one for Microsoft 365, a marketing platform or another service. A domain must not have multiple SPF records that could be selected during evaluation. Combine legitimate mechanisms into one record. Multiple quoted strings within one DNS TXT record are different: DNS providers may split a long value into strings, and SPF evaluators concatenate them. RFC 7208 covers multiple SPF records and TXT strings.

Should native senders use -all or ~all?

For a known, complete inventory of permission-based sending systems, finish with -all. This is the clearest declaration that unlisted sources are not authorised.

~all produces an SPF softfail rather than a fail. It can be a short-lived diagnostic choice where the organisation genuinely does not yet know all of its legitimate sources, but it is not a substitute for completing the inventory. Mailbox providers make their own delivery decisions, so a softfail is neither a delivery guarantee nor a safe permanent policy. Once the sending estate is understood and tested, move to -all.

A record ending ?all or +all does not meaningfully restrict unauthorised sources. It is unsuitable for a domain that expects SPF to contribute to authentication and DMARC.

Configure the SMTP server as well as DNS

DNS alone cannot correct an incorrectly configured mail transfer agent. The SMTP service must use the intended identities consistently.

Set the MAIL FROM address for each message type. For example, a password-reset message may use bounce@mail.example.com, while a product update might use newsletter-bounces@mail.example.com. Both query the SPF record at mail.example.com. Ensure the bounce mailbox or processing service exists and can receive delivery-status notifications; otherwise, bounces accumulate or disappear and list hygiene suffers.

Set the EHLO name to a real fully qualified hostname, such as smtp1.mail.example.com, rather than localhost, a private hostname or an IP literal. Publish an A or AAAA record for that hostname pointing back to the sending IP, and arrange reverse DNS with the IP-address provider so that the IP’s PTR record resolves to the same hostname. Google’s sender guidance requires valid forward and reverse DNS for sending domains or IPs, and specifies that the PTR hostname must resolve back to the public sending IP. Google’s email sender guidelines also call for TLS and appropriate authentication.

It is sensible to publish an SPF record for the EHLO hostname too when it is a separate host name:

Host/name: smtp1.mail
Type:      TXT
Value:     v=spf1 ip4:198.51.100.24 -all

This does not replace the SPF record for the MAIL FROM domain. It supports receivers that assess the HELO/EHLO identity and avoids presenting an SMTP hostname with no authorisation policy.

Keep SPF within its technical limits

SPF evaluation has a hard limit of ten DNS-querying terms. The terms that count include include, a, mx, ptr, exists and redirect. Nested includes count too. If the limit is exceeded, the required result is a permanent error (permerror), rather than a pass. The SPF DNS lookup limit in RFC 7208 is therefore an operational constraint, not merely a recommendation.

A native-only record with explicit ip4 and ip6 mechanisms is simple and does not consume DNS lookups at evaluation time. Complexity tends to appear when a corporate domain collects successive includes for workplace mail, transactional services, marketing platforms, support tools and legacy systems.

Count lookups whenever an include changes, and account for provider-side changes inside included records. Avoid the ptr mechanism: the SPF specification notes that it is slow, unreliable in the face of DNS errors and burdensome to DNS infrastructure. Reverse DNS remains important for mail-server reputation and identity, but it should be configured at the IP provider rather than used as an SPF mechanism.

If the root domain’s SPF record is crowded, a dedicated envelope subdomain for native sending can make the policy cleaner. For instance, mail.example.com may authorise only the application relays, while example.com covers corporate mail. This is a structural decision, not a way to bypass authentication requirements: the visible From domain, DKIM signing domain and DMARC policy must still work together.

SPF is necessary, but it is not enough

SPF authenticates the infrastructure used for the envelope sender. It does not authenticate the visible From header on its own, protect message content or survive every forwarding path. Forwarding can change the connecting IP while leaving the original SPF record untouched, causing SPF to fail at the final recipient.

DKIM provides a cryptographic signature that can continue to verify after ordinary forwarding, provided the signed portions of the message have not been changed. DMARC then checks whether a passing SPF or DKIM identity aligns with the visible From domain and applies the domain owner’s published policy.

For Gmail, all senders need SPF or DKIM, while senders of more than 5,000 messages a day to personal Gmail accounts need both SPF and DKIM, plus DMARC. Google also requires alignment for direct mail at that higher volume. Google’s sender-guidelines FAQ explains that non-compliance can lead to temporary or permanent failures or spam placement. Configure SPF as part of the authentication set, not as a single fix for deliverability.

For native transactional mail, a robust baseline is therefore: a controlled envelope sender domain with an accurate SPF record; DKIM signatures applied by the final outbound relay; a DMARC record for the visible From domain; matching forward and reverse DNS; TLS for SMTP transport; and working bounce processing. Permission, list quality, complaint rates and sending patterns still influence inbox placement after these basics pass.

Test the exact route that recipients see

After publishing the record, wait for the DNS change to become visible according to the record’s TTL and test mail from the production sending path. Do not rely solely on a DNS-control-panel preview.

Send a message to mailboxes at more than one major provider and inspect the full headers. Look for an Authentication-Results line confirming:

spf=pass smtp.mailfrom=bounce@mail.example.com
 dkim=pass header.d=example.com
 dmarc=pass header.from=example.com

The exact formatting varies by recipient. What matters is that SPF passes against the intended MAIL FROM domain, DKIM passes with an aligned signing domain, and DMARC passes for the visible From domain. Confirm the sending IP shown in the received headers is the one in the SPF record. This catches common problems such as cloud-provider IP changes, a second relay being used in production, unexpected IPv6 delivery, or a staging system accidentally sending live mail.

Also test a bounce or deliberately invalid recipient in a controlled manner. Check that the envelope sender is correct and that the resulting delivery-status notification reaches a monitored mailbox or processing endpoint. For messages using a null envelope sender, which are common for some automated notifications, SPF falls back to the HELO identity; that makes correct EHLO naming and its SPF policy especially useful.

Common native SPF mistakes

• Authorising the application server rather than the SMTP egress IP. Follow the actual outbound connection, including relays and NAT.
• Publishing SPF on the visible From domain when MAIL FROM uses another subdomain. SPF is looked up on the envelope domain.
• Creating multiple SPF TXT records. Merge authorised mechanisms into one SPF policy for each sending domain.
• Forgetting IPv6. A server can pass over IPv4 and fail when a recipient is reached through IPv6.
• Using mx because the domain receives mail there. An MX mechanism authorises the IP addresses of the domain’s inbound mail exchangers; it is not a shortcut for identifying outbound infrastructure.
• Adding every historic provider “just in case”. Remove unused authorisations and keep the policy understandable.
• Assuming SPF pass means DMARC pass. SPF must also align with the visible From domain unless aligned DKIM carries DMARC.
• Ignoring reverse DNS and EHLO. SPF cannot compensate for a mail server that identifies itself poorly or lacks valid forward and reverse DNS.

Where native infrastructure has several regions, mixed sending platforms or unclear historic ownership, the difficult work is usually discovering and validating every real sending path. An authentication and infrastructure review can establish that inventory before a strict SPF and DMARC posture is enforced. That is more reliable than making a record progressively broader whenever a delivery problem appears.

Frequently asked questions

Where do I publish an SPF record for native email sending?

Publish the SPF TXT record on the domain used after the @ in the SMTP MAIL FROM address. If the envelope sender is bounce@mail.example.com, publish it at mail.example.com. The visible From domain may be different.

Can I have more than one SPF record?

No. A single domain must not publish multiple SPF records that could be selected by an evaluator. Combine valid ip4, ip6 and include mechanisms into one SPF TXT record for that domain.

Should I use ip4 or include in a native SPF record?

Use ip4 and ip6 mechanisms for fixed public IP addresses that your native SMTP infrastructure uses. Use include only where a third-party provider that sends mail for your domain explicitly instructs you to include its SPF policy.

Does SPF need to match the From address?

SPF itself checks the MAIL FROM domain, not the visible From header. However, for SPF to satisfy DMARC, the SPF-authenticated domain must align with the From domain under the DMARC policy. Aligned DKIM can also satisfy DMARC.

Why does SPF pass in a test but mail still goes to spam?

SPF verifies sender authorisation only. Delivery decisions also consider DKIM, DMARC, reverse DNS, TLS, IP and domain reputation, recipient engagement, complaint rates, content, list quality and sending behaviour.

Sources and further reading

• RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 — IETF
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — IETF
• Email sender guidelines — Google
• Email sender guidelines FAQ — Google
• External Domain Name System records for Microsoft 365 — Microsoft Learn
• RFC 5321: Simple Mail Transfer Protocol — IETF