Help

Protection against spoofed email

Two records at your domain provider define who may send email in your name (SPF and DMARC).

Why this concerns your website

Anyone can write any sender on an email, just like on a letter. That way someone can send your customers an invoice with changed bank details from billing@your-company.com without you knowing. Two records in DNS, your domain’s public directory, tell mailboxes who may send in your name and what should happen to everything else. This is worth doing even if you don’t send any email from the domain.

We read both records from public DNS without contacting your server. We query the domain your site finally lands on, without www. If that is a subdomain such as shop.your-company.com, we look there first and then at your-company.com. If an app runs at a platform address such as name.lovable.app, the result applies to the platform’s domain. In that case, check your company domain separately.

Who may send in your name (SPF)

SPF is a list of the servers allowed to send email for your domain. It is a TXT record directly on the domain and starts with v=spf1. For Google Workspace it looks like this:

TXT · your-company.com
v=spf1 include:_spf.google.com ~all

For Microsoft 365 the part is include:spf.protection.outlook.com. If you also use a newsletter service or an invoicing tool, add one more include for each. The exact value is in their documentation. If you don’t send any email from the domain, this line is enough:

TXT · your-company.com
v=spf1 -all

We report when there is no SPF record or when it ends in +all. With +all anyone may send, so the record offers no protection. Also make sure there is only one SPF record. If there are two, mailboxes evaluate neither.

What happens to spoofed email (DMARC)

DMARC tells receiving mailboxes what to do with email that claims to come from you but fails the check. The record sits under _dmarc in front of your domain. Tighten it in three steps. That way no genuine email gets lost, for example from a service you forgot to include in SPF.

  1. Monitor. Nothing is rejected. You only receive reports at the address after rua. Let this run for two to four weeks and look at who is sending in your name.
TXT · _dmarc.your-company.com
v=DMARC1; p=none; rua=mailto:dmarc@your-company.com
  1. Quarantine. Spoofed email lands in the spam folder.
TXT · _dmarc.your-company.com
v=DMARC1; p=quarantine; rua=mailto:dmarc@your-company.com
  1. Reject. Spoofed email is not delivered at all.
TXT · _dmarc.your-company.com
v=DMARC1; p=reject; rua=mailto:dmarc@your-company.com

A missing record is a warning. A record set to p=none is a notice: spoofed email gets reported, but it still arrives.

Where to add the records

At the provider that holds your domain, in its DNS management. Create a new record of type TXT there. As the name, enter @ for SPF or leave the field empty, and _dmarc for DMARC. It can take a few hours until the change has propagated everywhere. Then check again.

We don’t check the DKIM email signature. For that we would need to know the name of the key, and only your email provider assigns it. Set it up anyway if your provider offers it.

Still have questions? Email us.

Is your app
watertight?

Hullwise finds the leaks before someone else does: exposed keys, database credentials and outdated software. Every finding comes with steps to fix it.

https://

Click a finding to mark it as fixed.

See pricingHow a scan works

Ship fast. Stay hullwise.