Email to SMS and sender verification: SPF, DKIM, DMARC

Email to SMS sends a text when you email a mobile number at a gateway's address, which means the gateway has to decide who is allowed to send. The trouble is that the From line on an email is only text. RFC 7208, the SPF standard published in April 2014, puts it bluntly: email protocols "place no restriction on what a sending host can use as the "MAIL FROM" of a message". Three standards exist to settle the question for a domain: SPF, DKIM (RFC 6376, September 2011) and DMARC, which the IETF republished on its Standards Track as RFC 9989 in May 2026. In the last sector-by-sector figures the NCSC published, enforcement in the UK ranged from all the central government organisations it tracked to 17% of the largest charities and 9% of a sample of schools.

This post covers what email to SMS does, why an address alone proves nothing, what each of the three standards checks, and what to set up on your side so that email you send, to a gateway or anyone else, can be told apart from a forgery.

How does email to SMS work?

You write an email to a mobile number followed by the gateway's domain, something like 07700900123@sms.example.co.uk, and the gateway turns the body into a text to that number. Nothing to install, no code to write, which is why it suits systems that can send an email and nothing else: a booking system with no SMS option, a monitoring tool that emails when a freezer warms up, a rota sent from a shared mailbox, a member of staff who lives in Outlook.

The gateway's side of it is harder. Every text costs credit and goes out under your business's name, so before it sends anything the gateway has to be confident the email came from someone allowed to send on your account. Our email to SMS page shows how that works in practice.

Why doesn't a From address prove who sent an email?

Because email lets any server claim any name. RFC 7208 says so in its first section: "any host injecting mail into the system can use any DNS domain name it wants in each of the various identifiers". RFC 9989 opens with the consequence: "Abusive email often includes unauthorized and deceptive use of a domain name in the "From" header field."

There are two "from" addresses on every email, which is half the confusion. The envelope sender (MAIL FROM) is given to the receiving server during delivery and is where bounces go. The From header is what your mail program shows. They're often the same and needn't be. SPF checks the first. DKIM signs with a domain of its own choosing. RFC 9989 points out that both "provide domain-level authentication but are not directly associated with the RFC5322.From domain", the visible one. DMARC is the piece that joins them up.

What do SPF, DKIM and DMARC each check?

The NCSC's email security guidance has the shortest summary going. SPF "allows you to publish IP addresses which should be trusted for your domain". DKIM "allows you to cryptographically sign email you send to show it's from your domain". DMARC "allows you to set a policy for how receiving email servers should handle email which doesn't pass either SPF or DKIM checks", and it "also generates reports".

The link DMARC adds is called alignment. Under RFC 9989 a DMARC pass needs an SPF or DKIM pass, and it needs the domain behind that pass to be "aligned" with the Author Domain, the one in the From header. Relaxed alignment means the same organisational domain (mail.example.co.uk lines up with example.co.uk); strict means identical. So a forger who sends from their own server, with their own valid SPF and DKIM for their own domain, still fails DMARC when they put your domain in the From line.

The policy says what you'd like done with failures. With "none", the domain owner "offers no expression of preference". With "quarantine", the owner "considers such mail to be suspicious". With "reject", the owner "considers all such failures to be a clear indication that the use of the domain name is not valid". The receiver decides in the end; RFC 9989 says a receiving organisation "can choose to honor the Domain Owner's requested message handling for validation failures, but it is not required to do so". And a pass is no endorsement of the content: it "does not guarantee that delivery to the recipient's inbox would be safe or desirable".

RFC 9989 replaced RFC 7489, published in March 2015 as an informational document, and dropped one tag on the way. The old "pct" tag let owners apply a policy to a percentage of failing mail, and "operational experience showed that the "pct" tag was usually not accurately applied, unless the value specified was either 0 or 100". Its replacement is a simpler test-mode flag, "t".

How widely is DMARC enforced in the UK?

The best UK figures come from the NCSC's Mail Check service, which tracked public sector and charity domains until the NCSC retired it on 31 March 2026. Its last sector-by-sector table, in the Active Cyber Defence report for its sixth year (published on 6 July 2023), gives the position at the end of 2022. "In 2022, we reached the landmark of 100% of all central government organisations adopting a strict DMARC policy", meaning quarantine or reject. Local government and the police and fire services were at 87%, universities at 29%, the top 3,000 charities by income at 17%, and a sample of 1,000 schools at 9%.

The same report shows what enforcement does. Over a 30-day period, ministerial departments saw 83,373,427 spoofed emails sent in their name, and DMARC blocked 83,020,928 of them, 99.6%. In health, where many legacy domains had no strict policy, a quarter were blocked. The NCSC also describes one large public body whose domain was being spoofed "with up to 40,000 emails per day" until a strict DMARC policy stopped it.

For everyone else, the push has come from the mailbox providers. Since 1 February 2024 Google has required anyone sending more than 5,000 messages a day to Gmail accounts to "set up DMARC email authentication for your sending domain", with the From domain aligned to the SPF or DKIM domain, although "your DMARC enforcement policy can be set to none". Our post on Gmail, Yahoo and Outlook sender rules covers the rest of those requirements.

How do you get to a policy of reject?

The NCSC's implementation plan ends with "a DMARC policy of 'reject' on all of your domains", and gets there in stages: publish SPF, sign with DKIM, start DMARC at none with reports switched on, then quarantine, then reject. Its advice on the last step: "As soon as you are confident DKIM and SPF are continuing to work correctly, you should move to a DMARC policy of 'reject'." It suggests monitoring reports "for at least a 2-week period" around the change, and notes that many organisations moved from quarantine to reject "after about 3 months". (The NCSC page still shows a pct value in its example record, from before RFC 9989 retired that tag.)

RFC 9989 is more cautious still for domains whose staff post to mailing lists: publish none "for at least a month", then quarantine "for an equally long period of time", and compare the results before going further.

The reports are what make it safe. Systems that send mail as your domain show up in them, including the ones you'd forgotten: the booking platform, the accounts package that emails invoices, the website contact form. Each needs to be covered by your SPF record or to sign with DKIM for your domain before you reach reject, or its mail will start failing.

Why does forwarded email fail DMARC?

RFC 9989 spends a section on forwarding, and admits that "few organizations consider the effect of DMARC policies on their users' indirect mail". When an email goes through a relay (an alumni forwarding address, a role address like finance@ that passes mail to whoever holds the job, a mailing list), it arrives from the relay's server, not yours. So it "will most likely fail SPF checks", while "DKIM signatures will generally remain valid in these relay situations". The NCSC makes the same point in fewer words: DKIM "has the advantage of being able to support forwarded email".

Hence the rule in the RFC that domains publishing reject "MUST NOT rely solely on SPF to secure a DMARC pass and MUST apply valid DKIM signatures to their messages". The same section tells receiving servers they "MUST NOT reject incoming messages solely on the basis of a "p=reject" policy", and should weigh it with what else they know. If any of your systems send through a forwarding address, DKIM is the part that keeps their mail recognisably yours on the far side.

What does this mean if you use email to SMS?

Any email to SMS gateway has to establish the sender some other way than by trusting the From line, because anyone can type that line. What you control is the rest of the chain, whichever gateway you use:

• Authenticate the domain your systems send from, with SPF, DKIM and a DMARC policy you've moved past none. That protects every email you send, to a gateway or to a customer.
• Keep the list of addresses allowed to text on your account short. One per system or person, named so you know what each is.
• Take people off it when they leave, the same day you remove their login. A shared mailbox on the list gives everyone who can send from it the ability to text your customers.
• Use email to SMS for the texts people expect (confirmations, alerts, answers), and keep marketing for a tool built for it, sent only to people who've agreed and with an opt-out line.

CaptiFi Connect's email to SMS works from verified addresses only. Treat each address on that list the way you'd treat a login: if you wouldn't give its owner a password to your texting account, they shouldn't be on it.