SPF, DKIM and DMARC Explained for Founders

Quick answer: SPF evaluates whether a sending IP is authorized for the envelope domain. DKIM verifies signatures over covered message data. DMARC checks alignment with the visible From domain and publishes a requested handling policy. Configure the relevant DNS records, test actual messages, and review reports; authentication does not guarantee inbox placement or prevent every phishing attempt.

By Gabriel CA · Kraftwire Software

· 6 min read

Email authentication helps receivers evaluate domain authorization and message signatures. Configure it alongside delivery monitoring and account security; absent or incorrect records do not produce the same outcome at every receiver.

For an app built with Lovable or Bolt.new, identify every service that sends mail for your domain and review its configuration.

These live figures describe all scanned sites. They do not establish prevalence for an AI-built subgroup, compare development methods, or attribute findings to AI generation.

30% of the 119 live sites SimplyScan has scanned (36 sites) have at least one high or critical security issue.

Review email authentication separately from the aggregate web-scan figures. They do not establish the state of your domain’s mail configuration.

Why Do You Need SPF DKIM and DMARC Explained?

The visible From address is not by itself proof of domain authorization or a sender’s personal identity. Receivers use authentication results and other signals when deciding how to handle a message.

The mechanisms have different roles:

  • SPF: Evaluate authorization of a sending IP for the envelope domain.
  • DKIM: Verify a signature from a signing domain over covered message data.
  • DMARC: Check alignment with the visible From domain and publish a requested policy for messages that fail DMARC.

What Does SPF Check?

SPF publishes policy in a DNS TXT record for the domain being checked. Its mechanisms identify authorized sending IPs directly or through other records. Follow the sending provider’s documented settings.

The receiver evaluates the connecting IP against the SMTP MAIL FROM domain’s SPF policy, or the HELO domain when the reverse path is empty. SPF does not directly authenticate the visible From address.

The 10-Term Lookup Limit

SPF evaluation permits at most 10 DNS-querying mechanisms and modifiers, including recursive evaluation. Exceeding this returns permerror; it is not simply a count of all DNS packets. Entries such as include:google.com and include:sendgrid.net are examples to inspect, not a recommendation to copy them. Use your provider’s current values and assess the evaluated lookup path. See the SPF specification.

How Does DKIM Complement SPF?

DKIM verifies a signing domain’s signature over selected headers and message-body content. It is distinct from SPF’s sending-IP authorization and does not prove the identity or trustworthiness of the human author.

Configure signing at the sending service and publish its public-key records as instructed. A receiver uses the signature’s domain and selector to locate the key. Changes to covered data can invalidate the signature, subject to canonicalization and signing options. DKIM detects verification failures; it does not prevent modification.

For an app using AI coding tools, configure the actual mail-sending service and test messages from each workflow. Keep this distinct from API authentication.

What Does DMARC Add?

DMARC passes when SPF passes with alignment to the visible From domain, or a valid DKIM signature has an aligned signing domain. A failure of either mechanism alone does not necessarily fail DMARC. The domain’s policy requests handling for messages that fail the combined DMARC check.

DMARC policy values request different handling:

p=none

Requests no special handling based on DMARC failure. Receivers may still filter or reject mail using other signals.

p=quarantine

Requests that failing messages be treated as suspicious, for example by placing them in spam. The receiver controls final disposition.

p=reject

Requests rejection of failing messages. Receiver policy may override the request; DMARC does not prevent display-name impersonation or lookalike-domain phishing.

Review the DMARC specification and the current requirements of the receiving services you send to. Authentication and domain reputation are related inputs, not interchangeable guarantees.

How Do You Set Up These Records for a New App?

For an app deployed through Vercel or Netlify, first identify the service that actually sends mail.

Choose an Email Provider

Select a provider for the application’s sending requirements and follow its current authentication instructions.

Add SPF

Publish the provider’s required SPF policy for the appropriate envelope domain, consolidating authorized senders into a valid policy. v=spf1 include:amazonses.com ~all is an illustrative provider-specific value, not a universal template.

Add DKIM

Enable signing and publish the provider’s selector records. These may be TXT records or CNAMEs pointing to provider-managed keys; the count varies.

Add DMARC

A monitoring example is v=DMARC1; p=none; rua=mailto:admin@yourdomain.com. Replace the example domain and reporting address with values you control and configure reports before tightening enforcement.

Review Reports

Review aggregate reports sent by participating receivers and test actual messages from legitimate sending services. Reports are not a complete log of every recipient or message.

Enforce

After validating legitimate sender alignment, assess a transition to p=quarantine or p=reject, monitoring failures and delivery throughout.

What Are the Risks of Ignoring Email Security?

Incorrect authentication can affect acceptance and make domain impersonation harder to detect. Outcomes depend on receiver policy and other message signals.

Delivery Problems

Test transactional mail from Bubble or FlutterFlow workflows with representative receivers. Investigate authentication failures, bounces, and spam placement; no DNS configuration guarantees inbox delivery.

Impersonation

An attacker may forge a visible address such as support@yourstartup.com. An aligned authentication setup and a p=reject policy ask participating receivers to reject DMARC failures, but do not stop all phishing or lookalike domains. Review account security and application data access separately.

How Can You Audit Your Domain Health?

Check published records and test actual messages. Finding a DKIM public key in DNS does not establish that the intended sender signs with it or that receivers validate the signature.

SimplyScan’s email-security tool checks published SPF and DMARC configuration and probes supported DKIM selectors. A missing selector result is not proof that DKIM is absent. Review DNS and TLS observations separately; the scan does not verify every message or guarantee delivery.

The average security score across the 119 live sites SimplyScan has scanned is 86 out of 100.

29% of the 119 live sites SimplyScan has scanned (35 sites) have at least one medium-severity web-security issue, such as a missing Content-Security-Policy or HSTS header.

Investigate individual findings and coverage. These aggregate web figures do not identify email failures or guarantee discovery before users are affected. See the security scanner.

Summary Checklist for Founders

  • Review the SPF limit for DNS-querying terms.
  • Enable and test DKIM signing for each intended sender.
  • Review DMARC alignment and reporting, initially with p=none where appropriate.
  • Use supported domain-health observations alongside message tests.

Review authentication results and delivery behavior after changing these records. For more help securing your stack, check out our vibe-coding security checklist.

Pro Monitoring includes Pro scan credits for full reports. See pricing for the allowance associated with your chosen option.

SimplyScan’s free URL scan grades 8 dimensions: security, speed, SEO, AEO, accessibility, compliance signals, domain health, and email security. No signup is required. Review supported findings in AI-built apps alongside application tests. Pro Monitoring provides scheduled rescans with change alerts, uptime monitoring, and supported Slack/GitHub integrations.

Pro Monitoring costs $24/month.

Frequently asked questions

What is SPF and how does it work?

SPF evaluates a sending IP against the SMTP envelope domain’s published policy, with a HELO-domain check when the reverse path is empty. It does not directly authenticate the visible From address or prevent unauthorized sending. Evaluation has a limit on DNS-querying terms; inspect the actual policy and result.

Why is DKIM important for email security?

DKIM verifies a signing domain’s signature over covered message data. It does not prove the human author’s identity or prevent changes. A signature may survive forwarding when the covered content is preserved, but forwarding or mailing-list modifications can break it.

What does a DMARC policy actually do?

DMARC requires an aligned SPF pass or an aligned valid DKIM signature relative to the visible From domain. Its policy requests no special DMARC handling, quarantine, or rejection for DMARC failures. Receivers can apply local policy; participating receivers can also send reports.

What happens if I don't set up email authentication?

Incorrect or absent authentication can affect acceptance and impede domain-impersonation detection. Requirements differ by receiving service and sender category. Check current receiver requirements and actual delivery results; authentication does not guarantee inbox placement or prevent every phishing attempt.

How do I check if my SPF DKIM and DMARC are set up correctly?

Configure the actual sending provider, inspect published DNS records, test representative messages, and review authentication results and DMARC reports. SimplyScan supplies supported DNS observations, including probes of common DKIM selectors; these do not verify every signature or sender. Validate legitimate alignment before tightening DMARC policy.

What is the SPF 10-lookup limit and how do I fix it?

The SPF limit applies to DNS-querying mechanisms and modifiers during evaluation, including recursive evaluation. Exceeding the limit returns permerror. Remove obsolete entries and review provider instructions. Flattening records requires keeping addresses synchronized with provider changes; stale flattened records can authorize the wrong systems or omit legitimate senders.

Related guides

  • Email Security Explained | SPF, DKIM, and DMARC for App Builders · An email security audit reviews sender authorization, message signing, and alignment with the visible From domain. SimplyScan checks selected DNS-record signals; it does not validate delivered messages or guarantee delivery. Pair those findings with provider configuration, test messages, and delivery reports.
  • AES-256 and TLS 1.3 Explained | How Your Data Is Actually Protected · AES-256 is a symmetric cipher used in storage encryption and other systems. TLS 1.3 protects communications between endpoints. Neither corrects application access-control flaws or exposed credentials; review encryption configuration, key handling, and authorization alongside supported automated checks.
  • CORS Misconfigurations That Leak User Data (and How to Test For Them) · A CORS misconfiguration that reflects any request origin while allowing credentials lets malicious sites read your users' private API data. AI generators often create these permissive defaults to silence errors. To stay secure, use a hard-coded origin allow-list and test your API server-side with crafted Origin headers.
  • CVE-2025-48757 Explained: How to Check If Your Lovable App Is Affected · CVE-2025-48757 is a disputed record concerning insufficient database authorization in Lovable-generated sites. Frontend login screens cannot enforce database permissions. Audit your app’s table privileges, Row-Level Security policies, and server-side authorization, then test anonymous access and access between separate test accounts.

All security guides · Free security tools · Platform scanners · Security checklist