domainsecuritycheck

← Record Studio

SPF

SPF (Sender Policy Framework, RFC 7208) lists the servers that are allowed to send email for your domain. The policy is published as a single TXT record at the domain name it applies to — RFC 7208, Section 3 places each record “in the DNS tree at the owner name it pertains to, not in a subdomain under the owner name”. A subdomain does not inherit the record of its parent, so every domain that appears as an envelope sender needs its own; receivers check it against the envelope sender of every incoming message.

A domain must publish exactly one SPF record. If a TXT record starting with v=spf1 already exists, replace it or merge your mechanisms into it – a second record makes SPF fail permanently (permerror). The deprecated ptr mechanism should no longer be published and is never emitted here.
SPF evaluation permerrors above 10 DNS-querying terms (RFC 7208 §4.6.4): the a, mx, ptr, exists: and include: mechanisms and the redirect= modifier all count, and include:/redirect= targets bring their own terms on top. Some provider includes are a single lookup, others add four or more – check yours rather than guessing. ip4:, ip6:, all and exp= do not count towards the limit. Above it receivers return a PermError, and SPF then neither passes nor fails.

The record is published at exactly this name — the one shown under “Name/Host” below. Not at a prefixed name, and not at the apex unless you entered the apex: a subdomain does not inherit the record above it (RFC 7208, Section 3). Enter the domain that actually appears in your envelope sender.

~all (softfail) is the more forwarding-friendly choice once DMARC is in place: forwarded mail often fails SPF, and some receivers reject on an SPF hard fail before DMARC is evaluated at all (RFC 9989 §7.1) – even where an aligned DKIM signature would have passed. Such messages also never reach your aggregate reports, because the transaction ends before DATA. With DMARC in place both are correct; -all is the stronger signal to receivers that do not evaluate DMARC and is the right choice for non-sending/parked domains. Never publish +all or ?all – they authorize any sender.

Comma- or space-separated; CIDR ranges are allowed.

Comma- or space-separated; CIDR ranges are allowed.

Only tick these if the domain really publishes A/AAAA (resp. MX) records. Each of them uses one of the 10 DNS-querying terms whether or not it finds anything – and a lookup that comes back empty is a “void lookup”, of which RFC 7208 §4.6.4 says implementations SHOULD allow at most two before returning PermError. Two empty ticks therefore cost two terms, authorize nothing, and leave no room for a third empty lookup anywhere in your record.

Comma- or space-separated domains; one DNS lookup each, and includes expand recursively.

Reads your domain's MX records, detects the mail provider and adds its include:. MX describes inbound mail while SPF authorizes outbound — this suggestion covers your mailbox provider; add includes separately for any other service that sends on your behalf (newsletters, CRM, transactional email).

Other sending services (marketing / transactional)

Tick any service that also sends mail for your domain — newsletters, transactional/API email — to add its include:. These are outbound senders only; your mailbox provider comes from the button above. For services with per-region infrastructure (e.g. CodeTwo) pick the data-center region of your tenant — only that region's include belongs in the record. The dropdown starts on no region at all: this form cannot know your tenant, and an unset region leaves the include out rather than guessing one. Mind the 10-lookup limit: every include counts and expands recursively.

Records are built in your browser; “Load current record” has our server look up your domain’s DNS. Record Studio · Verify the result with the domain security check