Is my email in the EU? MX records, SPF senders and what they reveal
How MX records show who receives your mail, how SPF shows who sends it, and how to check both for EU jurisdiction yourself.
Two public DNS records answer most of this question. The MX record names the servers that receive mail for your domain. The SPF record names the services allowed to send mail as your domain. A domain can receive mail at an EU provider and still send newsletters, CRM mail or support tickets through US services, so you need to check both.
What does an MX record tell me about my email?
An MX (mail exchanger) record lists the hosts that accept mail for a domain. RFC 5321 defines how a sending server looks up the MX records of the recipient's domain and delivers to the listed hosts in order of preference.
The MX hostnames usually reveal the mailbox provider. Hostnames under a provider's own domain, such as Google's or Microsoft's mail domains, point to that provider. The IP addresses behind the hostnames point to the network that operates them.
MX records show only the first hop. If the MX points to a spam-filtering gateway, the gateway may forward mail to a mailbox hosted somewhere else. DNS does not show that second hop.
What does an SPF record tell me about who sends my email?
SPF (Sender Policy Framework) is defined in RFC 7208. A domain publishes it as a DNS TXT record starting with v=spf1. It lists the hosts that are authorised to send mail using the domain in the SMTP envelope sender (MAIL FROM) or HELO identity.
Each include: term delegates to another domain's SPF record. In practice, an include usually names a sending service: a newsletter tool, a CRM, a ticketing system or a transactional mail API. The ip4: and ip6: terms name networks directly, often the domain's own servers.
Every service listed in SPF can send mail as your domain. To do that, it handles the content of those messages and usually the recipient addresses.
Why can a domain receive mail in the EU but send it through US services?
Receiving and sending are configured separately. The MX record is set once, for the mailbox provider. Each new tool that sends mail, such as a newsletter platform or a help desk, asks you to add its own include to SPF.
Over time a domain collects senders. The mailbox can be at an EU provider while the marketing, sales and support mail runs through providers headquartered in the US.
Why does the provider's jurisdiction matter for email?
Under the US CLOUD Act, 18 U.S.C. § 2713, a provider of electronic communication service or remote computing service must comply with US disclosure obligations for data in its "possession, custody, or control", regardless of whether the data is located inside or outside the United States.
This is why staysin.eu looks at who controls a provider, not only where its servers stand. A US company's EU data center is still operated by a company subject to that statute. The methodology explains the criteria: operating country, parent company, and whether the provider resells a non-EU service.
Check both directions. MX shows who receives your mail. SPF shows who sends it on your behalf. Either one can take mail content outside EU jurisdiction.
How does staysin.eu check mail and mail sending?
The Mail check reads the domain's MX records. It matches the MX hostnames against the provider list. If no hostname matches, it resolves the mail host to an IP address and matches it by IP prefix or by ASN (the number that identifies the network operator). The result is one scored item.
The Mail sending check reads the domain's SPF record. Includes that stay inside the domain's own zone are followed. Includes that point to another domain are treated as a sender and matched against the provider list by hostname. The ip4: and ip6: networks are attributed to their operator by IP prefix or ASN.
staysin.eu creates one Mail sending item per distinct provider. A provider that appears in several includes is counted once. A sender that is the same provider as the Mail item is left out, so the mailbox provider is not counted twice.
Some includes match no known provider. For those, staysin.eu looks up the include's own SPF tree, samples one listed network, and classifies the include by that network's ASN. Includes where no network can be found are grouped into one neutral item that does not affect the verdict. Private and unrouted networks are skipped.
Each Mail sending item is scored like the other layers. One non-EU sender is enough for the verdict "Leaves EU". You can see how individual providers are classified in the provider index, for example Google Workspace, Microsoft 365 or Mailchimp. Aggregate results across checked domains are on the stats page.
How can I check my MX and SPF records myself?
Use dig on Linux or macOS. Replace example.com with your domain.
dig +short MX example.com dig +short TXT example.comFor example.com the answers are 0 . and "v=spf1 -all", among other TXT records. The 0 . answer is a "null MX" (RFC 7505), which means the domain accepts no mail. The SPF record v=spf1 -all authorises no one to send. A domain that uses mail looks more like this illustrative output:
10 mx1.mailhost.example. 20 mx2.mailhost.example. "v=spf1 include:_spf.newsletter.example include:mail.helpdesk.example ip4:192.0.2.10 -all"Read the MX hostnames to find the mailbox provider. Read each include: to find a sending service. Look up an unfamiliar include with dig +short TXT to see what it delegates to. Look up the owner of an ip4: network with a whois or RDAP query.
To run the same checks in one step, enter your domain in the check form or open a URL like staysin.eu/example.com.
What are the limits of checking SPF?
SPF lists who is authorised, not who actually sends. An include for a tool you stopped using still appears until you remove it.
SPF covers the envelope sender domain. Some sending services use their own envelope domain, so they do not appear in your SPF record at all. DKIM signatures can reveal those services, but staysin.eu does not check DKIM.
RFC 7208 limits an SPF evaluation to 10 DNS-querying terms. A record that exceeds the limit produces a permanent error ("permerror") when a receiving server evaluates it.
What can I do if my mail leaves the EU?
Start with an inventory. List every MX host and every SPF include, and find the business owner of each sending tool.
Remove includes for tools you no longer use. For the rest, decide whether the data that tool handles needs to stay under EU jurisdiction.
EU-based providers exist for mailboxes, newsletters and transactional mail. The provider index lists how each known provider is classified. After a change, check your domain again to confirm the result.