CI/CD Guide

How to Automate DNS and Email Security Checks in CI/CD Without an API Key

You can catch many email DNS mistakes with shell scripts and GitHub Actions before you wire in an API. Start with simple checks, then move to structured audits when you need recursive SPF, DKIM selector coverage, scoring, and fix-plans.

This guide covers the no-key baseline. The Veldica API is the upgrade path when simple DNS lookups stop being enough.

Get CI/CD Check Kit API vs dig

What You Can Check Without an API Key

Raw DNS checks are useful for fast CI/CD guardrails. They can confirm that key records exist and that clear policy values are present:

  • MX exists for domains that receive mail.
  • SPF exists at the apex.
  • SPF ends in an intentional qualifier such as -all or ~all.
  • DMARC exists at _dmarc.example.com.
  • DMARC includes a policy value such as p=none, p=quarantine, or p=reject.
  • MTA-STS TXT exists at _mta-sts.example.com.
  • TLS-RPT TXT exists at _smtp._tls.example.com.

What You Cannot Reliably Check With Raw DNS

Simple dig checks do not give you a full audit engine. They do not handle these checks well:

  • recursive SPF lookup count,
  • DKIM selectors unless you already know them,
  • provider-aware context,
  • SPF and DKIM alignment interpretation,
  • prioritized remediation,
  • report rendering for teammates or clients.

Optional Strict Mode

Use strict mode when the domain sends production mail and your team wants CI to block risky changes. A strict version might fail if DMARC is missing, SPF is missing, or DMARC is still in p=none after your team has approved enforcement.

Use warning mode for parked domains, early setup, and domains where another team owns DNS. Warning mode keeps the issue visible without blocking unrelated releases.

When to Use Veldica

Move from raw DNS checks to Veldica when you need:

  • structured JSON instead of shell output,
  • recursive SPF lookup logic,
  • DKIM coverage with known selectors,
  • confidence notes for non-mail domains,
  • fix-plans and report output,
  • before-and-after comparison after a DNS change.

Which path should you use?

Need Best path
Learn the CI/CD baseline This guide
Need one fixed output Request the CI/CD kit
Need recurring checks Use the Veldica API
Need custom implementation Request a separate partner or custom review
Want a free web-checker preview Email Domain Trust Checker

Basic shell check

Use this as a minimal starting point for a CI job. Replace example.com with a domain from your deployment or DNS-change workflow.

Request
#!/usr/bin/env bash
set -euo pipefail

DOMAIN="${1:-example.com}"

dig +short MX "$DOMAIN"
dig +short TXT "$DOMAIN" | grep -i "v=spf1"
dig +short TXT "_dmarc.$DOMAIN" | grep -i "v=DMARC1"
dig +short TXT "_mta-sts.$DOMAIN" | grep -i "v=STSv1" || true
dig +short TXT "_smtp._tls.$DOMAIN" | grep -i "v=TLSRPTv1" || true

GitHub Actions example

This workflow fails when DMARC is missing and warns when SPF is missing. It keeps the baseline cheap while making DNS drift visible during changes.

  1. Add the script to scripts/check-email-dns.sh.
  2. Pass the domain as a workflow variable or repository secret.
  3. Fail the job for records your team treats as release blockers.
  4. Keep MTA-STS and TLS-RPT as warnings until your receiving-mail posture is ready.
.github/workflows/email-dns-check.yml
name: Email DNS checks

on:
  pull_request:
    paths:
      - "dns/**"
      - ".github/workflows/email-dns-check.yml"

jobs:
  email-dns:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install dig
        run: sudo apt-get update && sudo apt-get install -y dnsutils
      - name: Check required email DNS
        run: |
          chmod +x scripts/check-email-dns.sh
          scripts/check-email-dns.sh "${DOMAIN}"
        env:
          DOMAIN: example.com

Keep Exploring

Use the Workflow Library to browse more guides, comparisons, and integration examples to continue your evaluation.

Reports & Kits
CI/CD Email Security Check Kit

Get a repo-ready YAML, shell script, checklist, and sample failure output for your target domain.
Comparison
Veldica vs dig

See where raw lookups stop and structured audit output starts.
API
RapidAPI Quickstart

Move from no-key shell checks to API-backed audit automation.

Turn the baseline into a reusable CI check

Start with shell and GitHub Actions when you need a no-key guardrail. Use the fixed-output kit when you want the files, checklist, and strict-mode decisions packaged for your repo.

Request CI/CD Kit Build API-Backed Checks