DNS & Security Configuration Guide

Step-by-step instructions for fixing the issues found by the QShield Security Checkup. Click any section below to jump straight to the guide you need.

Email Authentication

SPF Record

Sender Policy Framework (SPF) is a DNS TXT record that tells receiving mail servers which IP addresses and hosts are allowed to send email on behalf of your domain.

Why it matters: Without SPF, anyone can forge emails that appear to come from your domain. SPF is the first layer of email authentication and is required by most mail providers and cyber insurance policies.

How to configure SPF

  1. Log in to your domain registrar or DNS hosting provider (e.g. GoDaddy, Cloudflare, Namecheap).
  2. Navigate to DNS Management and find the section for adding records.
  3. Add a new TXT record with the following values:
    Type: TXT
    Host: @
    Value: v=spf1 include:_spf.google.com ~all
    TTL: 3600
    Replace include:_spf.google.com with the SPF include for your email provider:
    • Google Workspace: include:_spf.google.com
    • Microsoft 365: include:spf.protection.outlook.com
    • Zoho Mail: include:zoho.com
  4. If you use multiple providers (e.g. a transactional email service), combine them in a single record:
    v=spf1 include:_spf.google.com include:sendgrid.net ~all
  5. Save the record and wait for DNS propagation (up to 48 hours, usually minutes).
  6. Re-run the QShield Security Checkup to verify.

Common mistakes

  • Having multiple SPF records — you must have exactly one. Combine all include: directives into a single TXT record.
  • Using +all — this allows anyone to send as your domain. Always use ~all (soft fail) or -all (hard fail).
  • Exceeding the 10-lookup limit — each include:, a, mx, and redirect counts as a lookup.
Email Authentication

DKIM Record

DomainKeys Identified Mail (DKIM) adds a cryptographic signature to every outgoing email. Receiving servers verify the signature against a public key published in your DNS, confirming the message hasn't been tampered with and genuinely came from your domain.

Why it matters: DKIM prevents email spoofing and tampering in transit. Without it, attackers can modify your emails or impersonate your domain. It's also required for DMARC alignment.

How to configure DKIM

  1. Generate your DKIM keys in your email provider's admin console:
    • Google Workspace: Admin Console → Apps → Google Workspace → Gmail → Authenticate Email → Generate New Record
    • Microsoft 365: Defender Portal → Policies → Email Authentication → DKIM
  2. Your provider will give you a DNS record to publish. It will look similar to:
    Type: TXT (or CNAME)
    Host: google._domainkey
    Value: v=DKIM1; k=rsa; p=MIGfMA0GCS...
  3. Add the record in your DNS provider exactly as shown. The selector (e.g. google, selector1) is unique to your provider.
  4. Go back to your email provider and enable / activate DKIM signing.
  5. Re-run the QShield Security Checkup to verify. Since DKIM selectors can't always be auto-discovered, you may be asked to send a verification email.

Common mistakes

  • Publishing the DNS record but not enabling DKIM signing in the provider console.
  • Using the wrong selector name — copy it exactly from your provider.
  • Line breaks or truncation — some registrars split long TXT records. Make sure the full key is published.
Email Authentication

DMARC Policy

Domain-based Message Authentication, Reporting & Conformance (DMARC) ties SPF and DKIM together. It tells receiving servers what to do when an email fails authentication — and where to send reports about it.

Why it matters: DMARC is the only way to instruct the world to reject forged emails from your domain. Without it, phishing emails using your domain can reach inboxes even if you have SPF and DKIM configured.

Policy levels

  • p=none — Monitor only. Emails that fail are still delivered but you receive reports. Start here.
  • p=quarantine — Failed emails are sent to spam/junk.
  • p=reject — Failed emails are blocked entirely. The goal.

How to configure DMARC

  1. Make sure SPF and DKIM are already configured and working.
  2. Add a TXT record in your DNS:
    Type: TXT
    Host: _dmarc
    Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
    TTL: 3600
  3. Replace dmarc-reports@yourdomain.com with an email address where you want to receive aggregate reports.
  4. Monitor reports for 2-4 weeks to make sure all legitimate mail is passing SPF/DKIM.
  5. Gradually tighten the policy: p=nonep=quarantinep=reject.

Recommended final record

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

adkim=s and aspf=s enforce strict alignment — the From domain must exactly match the SPF/DKIM domain.

DNS Security

DNSSEC

DNS Security Extensions (DNSSEC) adds cryptographic signatures to your DNS records, allowing resolvers to verify that responses haven't been tampered with during transit.

Why it matters: Without DNSSEC, attackers can perform DNS spoofing (cache poisoning) to redirect your visitors to malicious sites or intercept email. DNSSEC ensures the DNS answers your users receive are authentic.

How to enable DNSSEC

  1. Check your DNS host supports DNSSEC. Major providers like Cloudflare, AWS Route 53, and Google Cloud DNS support it. Some budget hosts do not.
  2. Enable DNSSEC at your DNS host:
    • Cloudflare: Dashboard → DNS → Settings → Enable DNSSEC. Cloudflare will display DS record details.
    • AWS Route 53: Hosted Zone → DNSSEC signing → Enable.
  3. Add the DS record at your domain registrar. Your DNS host will give you a DS record (key tag, algorithm, digest type, digest). Log in to your registrar (GoDaddy, Namecheap, etc.) and add it under DNSSEC settings.
    Key Tag: 2371
    Algorithm: 13 (ECDSAP256SHA256)
    Digest Type: 2 (SHA-256)
    Digest: abc123def456...
  4. Wait for propagation and verify using DNSViz or the QShield checkup.

Important notes

  • If your DNS host and registrar are the same company (e.g. both Cloudflare), the DS record may be added automatically.
  • Incorrect DNSSEC configuration can make your domain completely unreachable. Always verify after enabling.
DNS Security

CAA Record

Certificate Authority Authorization (CAA) is a DNS record that specifies which Certificate Authorities (CAs) are allowed to issue SSL/TLS certificates for your domain.

Why it matters: Without a CAA record, any CA in the world can issue a certificate for your domain. CAA prevents unauthorized certificate issuance, a technique used in man-in-the-middle attacks.

How to add a CAA record

  1. Determine which CA issues your SSL certificates. Common CAs:
    • Let's Encrypt: letsencrypt.org
    • DigiCert: digicert.com
    • Sectigo (Comodo): sectigo.com
    • Google Trust Services: pki.goog
  2. Add a CAA record in your DNS:
    Type: CAA
    Host: @
    Flag: 0
    Tag: issue
    Value: letsencrypt.org
  3. If you use multiple CAs, add one CAA record per CA.
  4. Optionally add an iodef record to receive notifications of unauthorized issuance attempts:
    Type: CAA
    Tag: iodef
    Value: mailto:security@yourdomain.com
  5. Save and verify with the QShield checkup.
Web Security

SSL / TLS Certificate

An SSL/TLS certificate encrypts the connection between your visitors' browsers and your web server, protecting data in transit from eavesdropping and tampering.

Why it matters: Without HTTPS, login credentials, form data, and browsing activity are transmitted in plain text. Browsers also display "Not Secure" warnings to visitors, damaging trust. SSL is mandatory for PCI compliance, SEO ranking, and cyber insurance.

How to get an SSL certificate

  1. Free option — Let's Encrypt: If your host supports it (most do), enable it in your hosting panel. Tools like Certbot can automate issuance and renewal:
    $ sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com
  2. Cloudflare: If you use Cloudflare, SSL is enabled automatically with their free plan. Go to SSL/TLS → set mode to Full (Strict).
  3. Hosting panel: cPanel, Plesk, and most managed hosts have a one-click Let's Encrypt option under "SSL/TLS" or "Security".
  4. Paid certificates: Purchase from DigiCert, Sectigo, or similar for extended validation (EV) or organization validation (OV) certificates if needed for compliance.

Keep certificates renewed

  • Let's Encrypt certificates expire every 90 days — Certbot auto-renews them if set up correctly.
  • Set a calendar reminder for paid certificates, or use monitoring (QShield checks this automatically).
  • Always redirect HTTP to HTTPS to prevent unencrypted connections.
Web Security

HSTS Header

HTTP Strict Transport Security (HSTS) is a response header that tells browsers to always use HTTPS when connecting to your site — even if the user types http://.

Why it matters: Without HSTS, the first request to your site may go over plain HTTP before being redirected, leaving a window for man-in-the-middle attacks. HSTS eliminates this by instructing browsers to never attempt an insecure connection.

How to enable HSTS

  1. Make sure HTTPS is fully working first (see the SSL section).
  2. Add the header in your web server configuration:

    Nginx:

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

    Apache (.htaccess or config):

    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

    Cloudflare:

    SSL/TLS → Edge Certificates → Enable HSTS. Set max-age to 12 months and enable includeSubDomains.

  3. Start with a shorter max-age (e.g. 300 = 5 minutes) to test, then increase to 31536000 (1 year).
  4. Once confident, submit your domain to the HSTS Preload List for maximum protection.

Important notes

  • Once preloaded, removing HTTPS is extremely difficult. Only preload when you're sure HTTPS will be permanent.
  • includeSubDomains applies to all subdomains — make sure they all support HTTPS.
Web Security

Security Headers

HTTP security headers are response headers that instruct browsers to enable built-in security features, protecting your visitors from cross-site scripting (XSS), clickjacking, MIME sniffing, and other attacks.

Why it matters: Security headers are a low-effort, high-impact defense layer. They cost nothing to implement and protect against some of the most common web attacks.

Recommended headers

X-Content-Type-Options — Prevents MIME type sniffing:

X-Content-Type-Options: nosniff

X-Frame-Options — Prevents clickjacking by blocking iframing:

X-Frame-Options: DENY

X-XSS-Protection — Enables the browser's XSS filter (legacy, but still recommended):

X-XSS-Protection: 1; mode=block

Referrer-Policy — Controls how much referrer information is shared:

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

Permissions-Policy — Restricts browser features (camera, mic, geolocation):

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

Content-Security-Policy (CSP) — Controls which resources the browser can load. Start with a report-only policy:

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

How to add these headers

Nginx — add to your server block:

add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

Apache (.htaccess):

Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "DENY"
Header always set X-XSS-Protection "1; mode=block"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"

Cloudflare: Use Transform Rules (Modify Response Header) to add each header, or deploy them on your origin server.

Still need help? Run a free scan to see exactly what needs fixing.

Run Free Security Checkup