Skip to main content
ConfigView reads your Mailgun account through the Mailgun API, using a single API key that a Mailgun admin creates. The key is sent as HTTP Basic auth (user api, the key as the password). You will end up with 1 required secret (MAILGUN_API_KEY) and 1 optional secret (MAILGUN_REGION, only for EU accounts) in ConfigView when setup is complete.
Scope of this integration today. ConfigView answers “who can send and receive email through our Mailgun account”: team members and their roles, API keys (kind, role, creator, expiry), sending domains and whether their SPF and DKIM records are verified, SMTP logins per domain, webhooks (where Mailgun posts events), inbound routes and forward rules (where mail is sent), subaccounts and the API IP allowlist. It never reads message content, mailing lists, templates, logs or suppression lists, and never stores a key value or SMTP password. ConfigView only reads. It never creates, changes or deletes anything in Mailgun.

​
What you need

  • A Mailgun account and a user who can create API keys (an Admin)
  • To know whether your account is in the US or the EU region. The EU region uses a different API host and a key from one region is rejected by the other

​
Step 1: Open the Mailgun page in ConfigView

Open ConfigView in a second browser tab and leave it open: https://{companyname}.configview.com/admin/integrations/mailgun

​
Step 2: Create an API key

  1. Sign in to Mailgun and open Settings → API Keys
  2. Click Add API key, name it ConfigView and choose a role (see the table below). If your plan does not offer role-based keys, the button is not there: you can only use the primary account API key, which has full access
  3. Copy the key straight away. Mailgun shows it once
  4. Switch to the ConfigView tab, paste it into MAILGUN_API_KEY under Credentials and click the save icon. Paste only the key, without api: in front
  5. EU accounts only: enter EU in MAILGUN_REGION. Leave it empty for the US region

​
Which role to give the key

No single read-only role reads everything in Mailgun, so you choose how much ConfigView can see. ConfigView only ever sends read requests, whichever role you pick. Roles cannot be changed after a key is created. To widen access, create a new key and revoke the old one. Mailgun’s role-based keys are only available on some plans. Give ConfigView its own key rather than sharing one with a script or a sending application. Then you can see exactly what it can do and revoke it without breaking anything else.

​
Step 3: Connect and verify

  1. Back on https://{companyname}.configview.com/admin/integrations/mailgun, confirm the credentials show as saved
  2. Click Connect. ConfigView creates its tables and schedules every collector at your default run time. Stop any you don’t want under Collectors:
  1. Click Verify now. The health check reads the secrets, calls /v4/domains (every role can read it), and then tries one request to each of the other areas.
If a check fails:
  • Mailgun API fails with 401. The key is wrong, was revoked, or belongs to the other region. If your account is in the EU, set MAILGUN_REGION to EU.
  • MAILGUN_REGION is not recognised. Use US or EU, or leave it empty.
  • Users, API keys or SMTP credentials show as skipped. The key’s role cannot read them (see the role table). Create a key with a wider role if you want that area; otherwise there is nothing to fix.
  • Forward rules or account webhooks show as skipped. The feature is not on your account.

​
Data Tables

Once the scripts run, these tables are created in your database. Each table has a run_at column and a raw_json column, which holds the record as Mailgun returned it, minus anything listed under What isn’t collected. Each table keeps only the newest run.

​
Things worth knowing

Check the role before you read the results. A table that is empty because the key’s role cannot read it looks the same as one with no records. The health check says which areas were skipped. There is no DMARC in the Mailgun API. Mailgun reports the state of the SPF, DKIM, MX and tracking CNAME records it asks you to publish. DMARC is a record you publish on your own DNS and Mailgun does not track it, so ConfigView cannot tell you whether a Mailgun domain has a DMARC policy. Domain state and DNS state. A domain is active once Mailgun has verified it. The per-record states (valid, invalid, unknown) are what Mailgun last saw; a record that was valid can turn invalid when DNS changes. invalid_records lists which ones. Routes are where inbound mail goes. A forward(...) action sends a copy of matching inbound mail to an address or a URL. ConfigView flags destinations that are not on a domain you send from (for example a personal mailbox). “Own” is judged by the last two labels of your Mailgun domains, so it can be wrong for suffixes such as .co.uk. SMTP credentials are names only. Mailgun returns the login, mailbox and creation date. Passwords cannot be read back. No usage or audit history. The API reports no last-used time for keys, no sign-in time for users and no audit log, so ConfigView cannot flag keys by last use or users by inactivity. Rate limit. Mailgun allows 500 requests every 10 seconds for the whole account, shared with your own sending integrations. Each ConfigView collector paces itself at 300 requests a minute and waits when Mailgun answers 429. Domains, tracking settings, SMTP credentials and webhooks make a request per domain.

​
What isn’t collected

  • API key values, SMTP passwords and the HTTP webhook signing key. The domain list returns each domain’s smtp_password; it is dropped before anything is stored
  • The full URL of a webhook, route or forward destination. Only its host is stored, because a path or query string can carry a secret
  • DNS record values (for example the DKIM public key), the unsubscribe footer text, each user’s last sign-in IP and preferences
  • Messages, logs, events, suppressions, mailing lists, templates, validations and metrics