E-postsäkerhet: SPF, DKIM och DMARC

SPF authorises all senders

The all mechanism decides what receivers do with mail from servers not listed in the record. +all authorises the entire internet; no all at all leaves it neutral.

Så åtgärdar ni det: End the record with -all (reject) once you are confident every legitimate sender is listed, or ~all (softfail) while you verify. Use your DMARC aggregate reports to find senders you have missed before tightening.

DMARC record missing

DMARC builds on SPF and DKIM to provide email authentication and reporting

Så åtgärdar ni det: Publish a DMARC TXT record at _dmarc.<your-domain> starting with v=DMARC1; p=none; rua=mailto:dmarc@<your-domain>. Monitor aggregate reports for 30 days, then graduate to p=quarantine and finally p=reject once SPF/DKIM are aligned for all legitimate senders.

Insufficient nameservers

Fewer than two nameservers means there is no redundancy in the one system every other service depends on. RFC 1034 has recommended at least two, on separate networks, since 1987.

Så åtgärdar ni det: Add at least one more nameserver, ideally with a different provider or at minimum in a different network and location. Most managed DNS providers supply four by default; if you are running your own, this is a strong argument for moving to a managed service.

SPF record missing

SPF prevents email spoofing by specifying authorized mail servers

Så åtgärdar ni det: Publish an SPF TXT record at the apex of your domain. Start with v=spf1 include:<your-mail-provider> ~all (e.g. include:_spf.google.com for Google Workspace, include:spf.protection.outlook.com for M365). After 30 days of clean DMARC reports, harden to -all.

DNSSEC not enabled

DNSSEC cryptographically signs DNS records to prevent spoofing

Så åtgärdar ni det: Enable DNSSEC at your DNS provider (Route53, Cloudflare, and Google DNS all offer one-click enablement). Verify the DS record is published at your registrar so the signing chain is anchored at the TLD; until the DS is in place at the registrar, DNSSEC is configured but not actually validated.

DMARC policy set to none

DMARC is published but set to p=none, which asks receivers to report on failures while still delivering the mail. It is the correct place to start, and the wrong place to stop.

Så åtgärdar ni det: Read your aggregate reports until every legitimate sender passes SPF or DKIM alignment, then move to p=quarantine (optionally with pct= to ramp gradually), and finally p=reject. Most domains stall at none indefinitely; treat this as a project with an end date rather than a permanent state.

SPF record invalid

An SPF record with a syntax error is not partially effective: receivers that cannot parse it generally treat it as permerror and ignore it entirely. The domain is left with no SPF protection while appearing configured.

Så åtgärdar ni det: Validate the record with an SPF checker. The usual causes are more than one v=spf1 record on the domain (only one is permitted), exceeding the ten-DNS-lookup limit, or a stray character. Consolidate to a single record and use include: for third-party senders.

CAA record missing

CAA records prevent unauthorized SSL certificate issuance

Så åtgärdar ni det: Publish CAA records naming your authorized CA(s), e.g. 0 issue "letsencrypt.org" and 0 issue "digicert.com". Add 0 iodef "mailto:security@<your-domain>" so you receive notifications when issuance is attempted by a non-authorized CA.

MTA-STS policy not enforced

MTA-STS tells sending servers to require TLS for your domain. In "testing" mode they report failures but deliver anyway, so the policy provides no actual protection.

Så åtgärdar ni det: Confirm from your TLS-RPT reports that legitimate senders are succeeding, then change the policy mode to enforce. Keep the same max_age so caches roll over cleanly.

SPF record has no all mechanism

The all mechanism decides what receivers do with mail from servers not listed in the record. +all authorises the entire internet; no all at all leaves it neutral.

Så åtgärdar ni det: End the record with -all (reject) once you are confident every legitimate sender is listed, or ~all (softfail) while you verify. Use your DMARC aggregate reports to find senders you have missed before tightening.

TLS reporting not configured

TLS-RPT is where receiving servers send daily reports about failures to deliver mail to you over TLS.

Så åtgärdar ni det: Publish a TXT record at _smtp._tls with v=TLSRPTv1; rua=mailto:.... Point it at a monitored mailbox or a reporting service; the reports are JSON and small.

DKIM key below recommended size

DKIM signatures prove a message really came from your domain. The strength of that proof is the key size; RFC 8301 sets 1024 bits as the floor and recommends 2048.

Så åtgärdar ni det: Generate a 2048-bit key at a new selector, publish it, switch signing to the new selector, then retire the old one after a fortnight so mail already in flight still verifies.