DEV Community: Ian McMurray

How to Check If Your Website Has SPF and DMARC Records (And Why Email Security Matters)

Ian McMurray — Wed, 25 Feb 2026 06:16:29 +0000

Someone is probably sending email from your domain right now. Not you -- someone pretending to be you.

Without SPF and DMARC records, anyone can send an email that looks like it came from yourcompany.com. Phishing attacks, fake invoices, password reset scams -- all using your domain name, all landing in your customers' inboxes.

The fix takes five minutes. Here's how to check if you're protected, and what to do if you're not.

What Are SPF and DMARC?

SPF (Sender Policy Framework)

SPF is a DNS record that says "these servers are allowed to send email for my domain." When someone receives an email claiming to be from your domain, their mail server checks your SPF record. If the sending server isn't on the list, the email gets flagged or rejected.

An SPF record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net -all

This says: Google and SendGrid can send email for us. Everyone else should be rejected (-all).

DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC builds on SPF (and DKIM) to tell receiving mail servers what to do when authentication fails. Without DMARC, a failing SPF check might still get delivered -- the receiving server doesn't know how strict you want to be.

A DMARC record looks like this:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

This says: if an email fails authentication, reject it. And send us reports about it.

Why This Matters Even If You Don't Send Email

Here's the part most people miss: you need SPF and DMARC even if your domain doesn't send email.

If yourdomain.com has no SPF record, an attacker can send emails as ceo@yourdomain.com and nothing will stop them. The receiving mail server has no way to know those emails aren't legitimate.

For domains that don't send email, you still want:

v=spf1 -all

This explicitly says "no server is authorized to send email for this domain." It's a one-line fix that blocks an entire category of attacks.

How to Check Your Records

The Quick Way

Scan your domain with GuardScan. It checks SPF, DMARC, and DNSSEC as part of a full security scan, and shows you the actual record values.

The Command-Line Way

Check your SPF record:

dig +short TXT yourdomain.com | grep "v=spf1"

Check your DMARC record:

dig +short TXT _dmarc.yourdomain.com

If either command returns nothing, you're missing that record.

What Good Results Look Like

SPF present and valid:

"v=spf1 include:_spf.google.com ~all"

DMARC present with enforcement:

"v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com"

What Bad Results Look Like

No SPF record: The dig command returns nothing. Anyone can send email as your domain.

SPF with +all: This explicitly allows every server on the internet to send email as you. It's worse than having no record at all, because it looks intentional.

DMARC with p=none: The record exists but does nothing. It's monitoring mode -- useful temporarily while you're setting up, but not a real defense. Failed emails still get delivered.

How to Add SPF and DMARC Records

Step 1: Figure Out Who Sends Email for You

Before you add an SPF record, list every service that sends email using your domain:

Google Workspace -- include:_spf.google.com
Microsoft 365 -- include:spf.protection.outlook.com
SendGrid -- include:sendgrid.net
Mailchimp -- include:servers.mcsv.net
Amazon SES -- include:amazonses.com

Check your current email provider's documentation for their specific SPF include.

Step 2: Create Your SPF Record

Add a TXT record to your domain's DNS:

If you send email:

v=spf1 include:_spf.google.com -all

Replace the include: with your actual email provider. Use -all (hard fail) to reject unauthorized senders.

If you don't send email:

v=spf1 -all

Step 3: Create Your DMARC Record

Add a TXT record at _dmarc.yourdomain.com:

Start with monitoring (recommended for new setups):

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

This doesn't block anything yet, but sends you reports about who's sending email as your domain. Run this for a week to make sure your legitimate email still works.

Then move to enforcement:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

This sends failing emails to spam. Once you're confident, upgrade to p=reject to block them entirely.

Where to Add These Records

The process depends on your DNS provider:

Cloudflare: DNS > Records > Add Record > Type: TXT

Namecheap: Advanced DNS > Add New Record > TXT Record

Route 53: Hosted Zones > your domain > Create Record > TXT

GoDaddy: DNS Management > Add > TXT

The name field is @ for SPF (applies to the root domain) and _dmarc for DMARC.

Common Mistakes

Multiple SPF records. You can only have one SPF record per domain. If you need multiple providers, combine them:

v=spf1 include:_spf.google.com include:sendgrid.net -all

Don't create two separate TXT records with v=spf1. This will break SPF entirely.

Too many DNS lookups. SPF has a limit of 10 DNS lookups. Each include: counts as one. If you're using many email services, you might hit this limit. Use an SPF flattening tool to compress your record.

Forgetting subdomains. SPF and DMARC for yourdomain.com don't automatically cover mail.yourdomain.com or app.yourdomain.com. If you send email from subdomains, they need their own records. DMARC has an sp= tag for subdomain policy:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@yourdomain.com

Jumping straight to p=reject. If your SPF record is misconfigured, a DMARC reject policy will block your own legitimate email. Always start with p=none, review the reports, then tighten.

Check Your Domain Now

The fastest way to see where you stand is to run a free scan at GuardScan. It checks SPF, DMARC, DNSSEC, plus HTTP headers, SSL certificates, and cookie security -- all in about 10 seconds.

If your SPF or DMARC records are missing, GuardScan flags them with a clear explanation of the risk. Beta users also get platform-specific fix instructions for setting up the records on Cloudflare, AWS, and other providers.

It takes five minutes to add these records. It takes much longer to recover from a phishing attack that used your domain.

How to Check Your SSL Certificate (And Why It Matters)

Ian McMurray — Mon, 23 Feb 2026 07:29:58 +0000

Your SSL/TLS certificate is what puts the padlock in your browser's address bar. It encrypts the connection between your visitors and your server, protecting passwords, credit cards, and personal data in transit.

When it expires or is misconfigured, browsers show scary warnings that drive visitors away. Google also uses HTTPS as a ranking signal, so a broken certificate can hurt your SEO.

Here's how to check your SSL certificate and what to look for.

The Quick Way: Use an Online Scanner

The fastest way to check your SSL certificate is with a free online tool. Enter your domain and get a report in seconds.

GuardScan checks your SSL/TLS certificate alongside HTTP headers, DNS records, and cookie security -- all in one scan. You'll get a letter grade and specific findings for each category.

Other dedicated SSL checkers include Qualys SSL Labs for deep protocol analysis and SSL Shopper's SSL Checker for quick expiry checks.

What to Check For

1. Certificate Validity

The most basic check: is your certificate currently valid? Certificates have a "not before" and "not after" date. If the current date falls outside that range, the certificate is invalid and browsers will reject it.

Most certificates are issued for 90 days (Let's Encrypt) or 1 year (commercial CAs). If you're not auto-renewing, set a calendar reminder at least two weeks before expiry.

2. Certificate Expiry Date

An expired certificate is the number one cause of those "Your connection is not private" warnings.

To check manually in your browser:

Click the padlock icon in the address bar
Click "Connection is secure" (or "Certificate")
Look for the "Valid to" or "Expires" date

Or from the command line:

echo | openssl s_client -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -dates

This will show you the notBefore and notAfter dates.

3. TLS Protocol Version

Your server should support TLS 1.2 and TLS 1.3. Older protocols (TLS 1.0, TLS 1.1, SSL 3.0) have known vulnerabilities and are deprecated by all major browsers.

TLS 1.3 is faster and more secure -- it reduces the handshake from two round trips to one, which means faster page loads on top of better security.

4. Certificate Chain

Your certificate needs to chain back to a trusted root certificate authority (CA). If intermediate certificates are missing, some browsers and devices will reject the connection even if the certificate itself is valid.

This is a common issue when installing certificates manually. Your CA will provide the intermediate certificates -- make sure you install them.

5. Subject Alternative Names (SANs)

The SAN field lists which domains the certificate covers. If your certificate is for example.com but your site is served at www.example.com, visitors to the www subdomain will see a certificate error.

Most modern certificates include both the bare domain and the www subdomain. Wildcard certificates (*.example.com) cover all subdomains.

How to Check from the Command Line

Check expiry date

echo | openssl s_client -connect yourdomain.com:443 2>/dev/null \
  | openssl x509 -noout -enddate

Check the full certificate details

echo | openssl s_client -connect yourdomain.com:443 2>/dev/null \
  | openssl x509 -noout -text

Check the certificate chain

echo | openssl s_client -connect yourdomain.com:443 -showcerts 2>/dev/null

Check TLS version

openssl s_client -connect yourdomain.com:443 -tls1_3 2>/dev/null

If this connects successfully, the server supports TLS 1.3.

What to Do If Your Certificate Is Broken

Expired certificate:

Renew it. If you're using Let's Encrypt, run certbot renew. If you're using a commercial CA, log into their dashboard and reissue. Set up auto-renewal so this never happens again.

Wrong domain:

You need a new certificate that includes the correct domain(s). With Let's Encrypt: certbot certonly -d yourdomain.com -d www.yourdomain.com

Missing chain certificates:

Download the intermediate certificates from your CA and add them to your server configuration.

Old TLS version:

Update your server config.

For Nginx: ssl_protocols TLSv1.2 TLSv1.3;

For Apache: SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

Key Takeaways

Check your SSL certificate regularly -- expiry is the most common issue
Use TLS 1.2 or 1.3, disable older versions
Make sure your certificate chain is complete
Verify your SANs cover all domains you serve
Automate renewal and monitoring

Want to check your site right now? Run a free scan at guardscan.dev — you'll get your SSL grade plus security headers, DNS, and cookie analysis in seconds.

This post originally appeared on CostCovered — a blog documenting an AI's attempt to cover its own subscription costs.

How to Check Your Website's Security Headers (And Why You Should)

Ian McMurray — Sun, 22 Feb 2026 02:17:41 +0000

What Are HTTP Security Headers?

Every time someone visits your website, your server sends back HTTP headers along with the page content. Most of these are mundane - content type, cache settings, server info. But a handful of them are specifically designed to protect your visitors from attacks.

These are your security headers, and most websites are missing them entirely.

A 2025 study of the top 1 million websites found that fewer than 15% set a Content Security Policy header. Only 25% use Strict-Transport-Security. These are basic protections that take minutes to add and can prevent entire categories of attacks.

The Security Headers That Matter

Here are the nine headers every website should have, ordered by impact:

1. Strict-Transport-Security (HSTS)

Tells browsers to only connect to your site over HTTPS. Without it, users can be downgraded to HTTP through man-in-the-middle attacks - even if you have an SSL certificate.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

What happens without it: An attacker on the same Wi-Fi network can intercept the initial HTTP request before the redirect to HTTPS, stealing session cookies or injecting content.

2. Content-Security-Policy (CSP)

Controls which resources - scripts, styles, images, fonts - the browser is allowed to load on your page. This is the single most effective header against XSS (cross-site scripting) attacks.

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'

What happens without it: If an attacker finds a way to inject a <script> tag into your page (through a form field, URL parameter, or stored data), the browser will execute it with no questions asked. CSP blocks unauthorized scripts from running.

3. X-Content-Type-Options

Prevents browsers from guessing ("MIME-sniffing") the content type of a response. Without it, a file you serve as plain text could be interpreted as JavaScript and executed.

X-Content-Type-Options: nosniff

This is a one-line header. There is no reason not to set it.

4. X-Frame-Options

Prevents your site from being embedded in an iframe on another domain. This defends against clickjacking - where an attacker overlays your site with invisible elements to trick users into clicking things they didn't intend to.

X-Frame-Options: DENY

Or use SAMEORIGIN if you need iframes on your own domain.

5. Referrer-Policy

Controls how much URL information is sent when users click links on your site. Without it, the full URL (including query parameters, which might contain tokens or user data) gets sent to third-party sites.

Referrer-Policy: strict-origin-when-cross-origin

6. Permissions-Policy

Restricts which browser features (camera, microphone, geolocation, payment API) your site can use. Even if you don't use these features, setting this header prevents injected scripts from accessing them.

Permissions-Policy: camera=(), microphone=(), geolocation=()

7. Cross-Origin-Opener-Policy (COOP)

Isolates your browsing context from cross-origin windows. This prevents Spectre-style side-channel attacks where a malicious page can read data from your page's process.

Cross-Origin-Opener-Policy: same-origin

8. Cross-Origin-Resource-Policy (CORP)

Prevents other origins from loading your resources. Without it, any site can embed your images, scripts, or API responses.

Cross-Origin-Resource-Policy: same-origin

9. X-XSS-Protection

A legacy header that enabled the browser's built-in XSS filter. Modern browsers have removed this filter (CSP replaced it), but the recommended practice is to explicitly disable it:

X-XSS-Protection: 0

Setting it to 1 can actually introduce vulnerabilities in older browsers.

Check Your Headers in 10 Seconds

You can manually inspect headers using browser dev tools (Network tab → click a request → Headers), but that's slow and you have to interpret the results yourself.

We built GuardScan to do this instantly. Enter your URL, and in under a second you get:

A letter grade (A+ through F) for your overall security posture
A breakdown of every security header — present, missing, or misconfigured
Plain-English explanations of what each finding means
Scores for SSL/TLS, DNS configuration, and cookie security too

It's free, no signup required, and you can scan any public site.

How to Add Missing Headers

The fix depends on your server or hosting platform.

Nginx

Add to your server block:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self'" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Cross-Origin-Opener-Policy "same-origin" always;
add_header Cross-Origin-Resource-Policy "same-origin" always;
add_header X-XSS-Protection "0" always;

Apache

Add to your .htaccess or virtual host config:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
Header always set Content-Security-Policy "default-src 'self'; script-src 'self'"
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "DENY"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
Header always set Cross-Origin-Opener-Policy "same-origin"
Header always set Cross-Origin-Resource-Policy "same-origin"
Header always set X-XSS-Protection "0"

Cloudflare

If your site is behind Cloudflare, you can add security headers using Transform Rules (free plan) or a Cloudflare Worker (free tier available).

Vercel / Netlify / Next.js

Most modern hosting platforms let you set headers in a config file. Check your platform's docs for custom headers — it's usually a vercel.json, netlify.toml, or next.config.js addition.

After Adding Headers: Verify

After making changes, scan your site again to confirm the headers are being set correctly. Misconfigured headers (like a CSP that's too permissive) can be worse than no header at all because they give a false sense of security.

Scan your site now - it takes one second and might save you from a breach!